Re: About operating system statistics

pull request available: https://github.com/apache/geode/pull/3574 [https://avatars3.githubusercontent.com/u/47359?s=400&v=4] GEODE-6660: Remove non-Linux OS statistics classes by alb3rtobr · Pull Request #3574 · apache/geode

Re: Geode self-protection about overload

The primary load limiter between the client tier and the Geode servers is via the max connections limit as noted in this writeup: https://cwiki.apache.org/confluence/display/GEODE/Resource+Management+in+Geode When

Backwards compatibility issue with JSONFormatter

I think the changes for GEODE-6327 broke backwards compatibility in JSONFormatter with the change from fromJSON(String jsonString) to fromJSON(String jsonString, String... identityFields) Adding an additional varargs parameter to the method breaks code that was compiled against the non-varargs ver

Re: Backwards compatibility issue with JSONFormatter

How did this slip the review process that the signature of a public API was changed? Well done Gester for finding this!! --Udo On 5/14/19 10:40, Dan Smith wrote: I think the changes for GEODE-6327 broke backwards compatibility in JSONFormatter with the change from fromJSON(String jsonString)

Re: Backwards compatibility issue with JSONFormatter

Hi all, This is my mistake - it was a misunderstanding of what constitutes a breaking public API change. If a client app were to recompile using the new bits with the new method signature, there wouldn't be an issue because the new signature would work with 0 varargs. The problem arises when you

Re: Permission for working on Jira

Now it’s working. Thank you Dan. Sent from my iPhone > On May 13, 2019, at 5:44 PM, Dan Smith wrote: > > Hi Geet, > > Welcome! I think I already gave you access to work with geode JIRAs earlier? > I see you listed as having access in JIRA. Is there something you are trying > to do that isn'

Re: Backwards compatibility issue with JSONFormatter

Sounds good! Yeah, this is a bit of an interesting case where code will still compile against the new API without change, but I think maintaining compatibility of the binary API is also important. Thanks for looking into it. -Dan On Tue, May 14, 2019 at 11:22 AM Ryan McMahon wrote: > Hi all, >

Re: Backwards compatibility issue with JSONFormatter

Here are a few links on API compatibility: https://lvc.github.io/japi-compliance-checker/#Examples https://wiki.eclipse.org/Evolving_Java-based_APIs https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html Anthony > On May 14, 2019, at 12:45 PM, Dan Smith wrote: > > Sounds good! Yeah, t

Re: Backwards compatibility issue with JSONFormatter

Thanks Anthony! Have we considered using a compliance checker in our CI like the one in the first link? Side note - I think that varargs is an interesting case that I don't see called out in those links. Since varargs is just syntactic sugar, it is ultimately the varargs parameter is converted t

Re: Backwards compatibility issue with JSONFormatter

Fixed in https://github.com/apache/geode/commit/cc0b37a504480f554b1884491f44a3cca4113ef5 On Tue, May 14, 2019 at 2:06 PM Ryan McMahon wrote: > Thanks Anthony! Have we considered using a compliance checker in our CI > like the one in the first link? > > Side note - I think that varargs is an int

Re: Backwards compatibility issue with JSONFormatter

It looks like the japi-compliance-checker tool to which Anthony linked is available as a gradle plugin: https://github.com/melix/japicmp-gradle-plugin On Tue, May 14, 2019 at 5:07 PM Ryan McMahon wrote: > Fixed in > > https://github.com/apache/geode/commit/cc0b37a504480f554b1884491f44a3cca4113ef