JIRA Access
I am currently acting as a product manager for geode native client component. I was wondering if I could have edit privileges for the Geode JIRA? Thanks, Charlie -- Charlie Black | cbl...@pivotal.io
Re: JIRA Access
Dan, Awesome and thanks! My username is charliemblack Charlie On Thu, Jan 3, 2019 at 3:17 PM Dan Smith wrote: > Hi Charlie, > > Sure, what's your user name in the apache JIRA? > > -Dan > > On Thu, Jan 3, 2019 at 3:02 PM Charlie Black wrote: > > > I am currently acting as a product manager for geode native client > > component. I was wondering if I could have edit privileges for the > Geode > > JIRA? > > > > Thanks, > > > > Charlie > > > > -- > > Charlie Black | cbl...@pivotal.io > > > -- Charlie Black | cbl...@pivotal.io
Re: Apache Geode PMC quarterly report: DRAFT for your review
+1 - Thanks for the mention of the native client! On Wed, Feb 13, 2019 at 9:05 AM Dave Barnes wrote: > I've incorporated Anthony's additions and an addition of my own (Karen > succeeded Mark as PMC chair). > Any other suggestions? Review closes at noon PST. > > On Wed, Feb 13, 2019 at 7:22 AM Anthony Baker wrote: > > > Under activity I would add: > > > > - Added benchmarks to baseline performance > > - Explored the use of micrometer for exposing metrics of cache operations > > > > Anthony > > > > > > > On Feb 12, 2019, at 3:34 PM, Dave Barnes wrote: > > > > > > Please respond by noon tomorrow. > > > Pretty complete, as far as I know, except for public events and > > > presentations. > > > Thanks, > > > Dave > > > > > > Description: > > > > > > Apache Geode provides a database-like consistency model, reliable > > > transaction processing and a shared-nothing architecture to maintain > very > > > low latency performance with high concurrency processing. > > > Issues: > > > > > > There are no issues requiring board attention at this time. > > > Activity: > > > > > > - We released v1.8.0, containing 124 improvements and new features, > > > resolving 83 bugs and a total of 380 JIRA tickets > > > - The v1.8.0 release includes the first release of the geode-native > > > source, a C++/C# client API for Geode. > > > - Security enhancements include support for Trust and Keystore > > rotation, > > > endpoint validation during SSL handshake, and dynamic function > > security. > > > > > > Health report: > > > > > > - Mailing lists remain active and productive. > > > - JIRA tickets show that issues continue to be identified and > resolved. > > > - We’re continuing to work on attracting new contributors and making > it > > > easier to participate in the community. > > > > > > PMC changes: > > > > > > - Currently 46 PMC members. > > > - No new PMC members added in the last 3 months > > > - Last PMC addition was Dick Cavender on Tue Feb 20 2018 > > > > > > Committer base changes: > > > > > > - Currently 98 committers. > > > - No new committers added in the last 3 months, but several > invitations > > > in the pipeline > > > - Last committer addition was Robert Houghton at Mon Oct 01 2018 > > > > > > Releases: > > > > > > - 1.8.0 was released on Wed Dec 12 2018 > > > > > > Mailing list activity: > > > > > > Mailing lists have remained active and have maintained consistent usage > > > levels. > > > > > > - > > > > > > dev@geode.apache.org: > > > - 193 subscribers (up 3 in the last 3 months): > > > - 465 emails sent to list (825 in previous quarter) > > > - > > > > > > iss...@geode.apache.org: > > > - 55 subscribers (up 0 in the last 3 months): > > > - 3342 emails sent to list (4259 in previous quarter) > > > - > > > > > > notificati...@geode.apache.org: > > > - 7 subscribers (up 0 in the last 3 months): > > > - 2500 emails sent to list (1865 in previous quarter) > > > - > > > > > > u...@geode.apache.org: > > > - 250 subscribers (up 0 in the last 3 months): > > > - 94 emails sent to list (212 in previous quarter) > > > > > > JIRA activity: > > > > > > - 357 JIRA tickets created in the last 3 months > > > - 314 JIRA tickets closed/resolved in the last 3 months > > > > > -- Charlie Black | cbl...@pivotal.io
Re: Dependency review for release 1.9.0
Hopefully, we are thinking about classpath of the server and lazily adding these jars only when a feature is turned on. On Thu, Feb 28, 2019 at 9:45 AM Dan Smith wrote: > I see that geo, grumpy-core, and commons math came from adding geospatial > support to redis - > > https://github.com/apache/geode/commit/7bf02251fd047cb1cf575c01b80a9807108618da > > -Dan > > On Thu, Feb 28, 2019 at 9:41 AM Anthony Baker wrote: > > > Looks a number of the new dependencies came in transitively with the > guava > > version bump. > > > > > On Feb 27, 2019, at 5:32 PM, Anthony Baker wrote: > > > > > > I was reviewing the release branch and noticed a number of new > > dependencies have been added since the last release. When you add a new > > dependency, please review and follow the project license guide [1]. In > > particular, update the LICENSE file in geode-assembly/src/main/dist > > depending on the license type. > > > > > > Currently we need to update the LICENSE file with the additional > > MIT/BSD/CDDL dependencies. We may also need to update NOTICE files. > > There’s also a version conflict with multiple versions of Jackson in use > > (2.9.6 / 2.9.8). > > > > > > @Sai - these need to be fixed on release/1.9.0 > > > > > > Here’s the list of additions: > > > > > > animal-sniffer-annotations-1.17.jar > > > checker-qual-2.5.2.jar > > > commons-math3-3.2.jar > > > error_prone_annotations-2.2.0.jar > > > failureaccess-1.0.jar > > > geo-0.7.1.jar > > > grumpy-core-0.2.2.jar > > > istack-commons-runtime-2.2.jar > > > j2objc-annotations-1.1.jar > > > javax.activation-1.2.0.jar > > > javax.activation-api-1.2.0.jar > > > jsr305-3.0.2.jar > > > listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar > > > > > > Removed: > > > > > > activation-1.1.1 > > > jaxb-core-2.2.11.jar > > > > > > Anthony > > > > > > [1] > > > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > > < > > > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > > > > > > > > > > > -- Charlie Black | cbl...@pivotal.io
Re: InternalCacheTransactionManager2PC removed from public API
The way transactions are done in Geode there shouldn't be any artifacts on the client side. For more info check out the chapter on transactions with Geode: https://geode.apache.org/docs/guide/16/developing/transactions/JTA_transactions.html On Fri, Apr 12, 2019 at 7:04 AM Jacob Barrett wrote: > Sorry for the delay. > > In the initial source grant it inadvertently in the public headers. Prior > to the 1.x release of Geode Native it was move internal where it belongs. > There is currently no way in Geode Native to get access to the two phases > commit transaction manager. This is an oversight that should be corrected. > Please open a JIRA asking for public API support for two phase commit > transactions. > > Thanks, > Jake > > > > On Apr 12, 2019, at 12:49 AM, Mario Ivanac > wrote: > > > > Hi, > > > > > > just reformulate this question. What is the way forward if we want to > use 2PC with C++ geode native? > > > > > > Regards, > > > > Mario > > > > > > Šalje: Mario Ivanac > > Poslano: 26. ožujka 2019. 8:42:57 > > Prima: dev@geode.apache.org > > Predmet: InternalCacheTransactionManager2PC removed from public API > > > > Hi, > > > > > > Can you tell me why is this header removed from geode native public API ( > https://issues.apache.org/jira/browse/GEODE-3421), > > > > and how we can use XA transactions (2PC) in geode native? > > > > > > BR, > > > > Mario > > -- Charlie Black | cbl...@pivotal.io
Re: [VOTE] Apache Geode 1.9.0 RC4
; > > > >> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4 < > > > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4> < > > > >> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4 < > > > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4>> > > > >> > > > >> Apache Geode Native: > > > >> > > > >> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4 < > > > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4> < > > > >> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4 < > > > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4>> > > > >> > > > >> > > > >> Commit ID: > > > >> > > > >> Apache Geode: c0a73d1cb84986d432003bd12e70175520e63597 > > > >> > > > >> Apache Geode Examples: b58b2720e9cb1fae9e2cbca7053bc9c748dab79d > > > >> > > > >> Apache Geode Native: add53da376c3044feb2fb22dc37a30989c271f19 > > > >> > > > >> > > > >> Source and binary files: > > > >> > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4 < > > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4> < > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4 < > > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4>> > > > >> > > > >> Maven staging repo: > > > >> > > > >> > > https://repository.apache.org/content/repositories/orgapachegeode-1054 > > > < > https://repository.apache.org/content/repositories/orgapachegeode-1054> > > < > > > >> > > https://repository.apache.org/content/repositories/orgapachegeode-1054 > > > < > https://repository.apache.org/content/repositories/orgapachegeode-1054 > > >> > > > >> > > > >> Geode's KEYS file containing PGP keys we use to sign the release: > > > >> > > > >> https://github.com/apache/geode/blob/develop/KEYS < > > > https://github.com/apache/geode/blob/develop/KEYS> < > > > >> https://github.com/apache/geode/blob/develop/KEYS < > > > https://github.com/apache/geode/blob/develop/KEYS>> > > > >> > > > >> > > > >> Signed the release with GPG fingerprint: > > > >> > > > >> DB5476815A475574577D442B468A4800EAFB2498 > > > >> > > > >> PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4 < > > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4> < > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4 < > > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC4>> > > > >> -PgeodeRepositoryUrl= > > > >> > > https://repository.apache.org/content/repositories/orgapachegeode-1054 > > > < > https://repository.apache.org/content/repositories/orgapachegeode-1054> > > < > > > >> > > https://repository.apache.org/content/repositories/orgapachegeode-1054 > > > < > https://repository.apache.org/content/repositories/orgapachegeode-1054 > > >> > > > >> build > > > >> runAll > > > >> > > > >> > > > >> Regards, > > > >> - Owen & Dan > > > > > > > > > -- Charlie Black | cbl...@pivotal.io
Re: Static Analysis Tools such as SonarQube or others?
I used SonarQube on a project it helped the team where to focus on next. The reports that it generates are extremely useful to help see how the code progresses over time across the many dimensions. On Tue, Jun 4, 2019 at 12:46 PM Mark Bretl wrote: > I have used SonarQube for many years, including integrating for the Geode > codebase in the past and using it now my current day job, and like it a > lot. The ASF hosts a server at https://builds.apache.org/analysis/, > however, the version is quite old and does not have features such as > Quality Gating or PR decoration. There is now a cloud version at > https://sonarcloud.io, which is free for open source projects. > > As Dan said, in order to make them productive, they need to be integrated > into the CI pipeline or the issues will end up as noise. > > --Mark > > On Tue, Jun 4, 2019 at 11:30 AM Dan Smith wrote: > > > We're currently running PMD as part of the gradle build. PMD is just > > running a couple of rules specifically to look for mutable statics. We've > > also enabled integration with lgtm to get a report - > > https://lgtm.com/projects/g/apache/geode/. > > <https://lgtm.com/projects/g/apache/geode/> > > > > I think added more static analysis is a good idea. I'm not that > particular > > about which tool(s) we are using - although maybe we should focus on open > > source tools? I do think that in order to be valuable, the static > analysis > > rules need to fail the build like we're doing with spotless and PMD. So I > > think an approach of cleaning up and enforcing one rule at a time is > better > > than just generating a report with a bunch of rule violations. > > > > -Dan > > > > > > On Tue, Jun 4, 2019 at 6:56 AM Peter Tran wrote: > > > > > Hi all, > > > > > > Has anyone had experience using static analysis tools such as > SonarQube? > > > Were there helpful? And favourites that worked well? > > > > > > Thanks > > > > > > -- Charlie Black | cbl...@pivotal.io
Re: Static Analysis Tools such as SonarQube or others?
Recommend run them all - It will at least enable the broader community to work on what is most important to them. On Wed, Jun 5, 2019 at 7:58 AM Peter Tran wrote: > From Dan: > >So I think an approach of cleaning up and enforcing one rule at a time is > better than just generating a report with a bunch of rule violations. > > Yes - Love this idea! > > > > On Tue, Jun 4, 2019 at 4:46 PM Charlie Black wrote: > > > I used SonarQube on a project it helped the team where to focus on next. > > The reports that it generates are extremely useful to help see how the > > code progresses over time across the many dimensions. > > > > > > On Tue, Jun 4, 2019 at 12:46 PM Mark Bretl wrote: > > > > > I have used SonarQube for many years, including integrating for the > Geode > > > codebase in the past and using it now my current day job, and like it a > > > lot. The ASF hosts a server at https://builds.apache.org/analysis/, > > > however, the version is quite old and does not have features such as > > > Quality Gating or PR decoration. There is now a cloud version at > > > https://sonarcloud.io, which is free for open source projects. > > > > > > As Dan said, in order to make them productive, they need to be > integrated > > > into the CI pipeline or the issues will end up as noise. > > > > > > --Mark > > > > > > On Tue, Jun 4, 2019 at 11:30 AM Dan Smith wrote: > > > > > > > We're currently running PMD as part of the gradle build. PMD is just > > > > running a couple of rules specifically to look for mutable statics. > > We've > > > > also enabled integration with lgtm to get a report - > > > > https://lgtm.com/projects/g/apache/geode/. > > > > <https://lgtm.com/projects/g/apache/geode/> > > > > > > > > I think added more static analysis is a good idea. I'm not that > > > particular > > > > about which tool(s) we are using - although maybe we should focus on > > open > > > > source tools? I do think that in order to be valuable, the static > > > analysis > > > > rules need to fail the build like we're doing with spotless and PMD. > > So I > > > > think an approach of cleaning up and enforcing one rule at a time is > > > better > > > > than just generating a report with a bunch of rule violations. > > > > > > > > -Dan > > > > > > > > > > > > On Tue, Jun 4, 2019 at 6:56 AM Peter Tran wrote: > > > > > > > > > Hi all, > > > > > > > > > > Has anyone had experience using static analysis tools such as > > > SonarQube? > > > > > Were there helpful? And favourites that worked well? > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > -- > > Charlie Black | cbl...@pivotal.io > > > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
I like the idea especially if its only for compile/test time and doesn't make it into the binary bits. On Fri, Jun 21, 2019 at 1:04 PM Udo Kohlmeyer wrote: > Thank you for the response... > > #1 - But isn't cyclical package dependent code not a smell and practice, > whilst at the same time and uni-directional dependency is preferred. > > Soo... I think I see the benefit to be more, that ArchUnit allows the > untangling of code into a modular way WITHOUT a big bang approach of > moving the code into modules and then having to be concerned about the > fallout. But also it allows for the managing of package dependencies > WITHOUT breaking the code out into different separate modules. > > I really like ArchUnit :).. We should prioritize adoption :) > > --Udo > > On 6/21/19 12:48, Murtuza Boxwala wrote: > > Two things come to mind: > > > > 1) uni-directional dependency > > Packages can be dependent on each other, because the classes inside of > them can use each other. e.g. let’s say package A has class A1 and class > A2 and package B has class B1 and B2. A1 can depend on B1, and B2 can > depend on A2. Hence, the packages are dependent on each other. > > > > Modules can only have uni-directional dependency. If Module A depends on > Module B, then no class in Module B can reference a class in Module A. > This prevents tangling, i.e. spaghetti > > > > 2) Incremental compilation > > This lack of tangling helps not only developers, but the compiler too. > In the packages example above, if I change any of the classes, all the code > has to get recompiled because the dependency lines can go in any direction, > and the compiler won’t attempt to optimize. In the modules case, if Module > A changes, Module B will not recompile, because the dependency guarantees > that nothing about Module B could have been affected. > > > >> On Jun 21, 2019, at 2:14 PM, Udo Kohlmeyer wrote: > >> > >> I know that I'm missing the benefit of physically moving the code from > the package into its own module. > >> > >> Could you possibly explain to me what it is? > >> > >> On 6/21/19 07:37, Murtuza Boxwala wrote: > >>> I think that’s a really clever way to increment toward splitting > geode-core into more modules. I am excited to see what it looks like 👍 > >>> > >>>> On Jun 20, 2019, at 7:45 PM, Jacob Barrett > wrote: > >>>> > >>>> Gotcha! Sounds good. > >>>> > >>>>> On Jun 20, 2019, at 4:35 PM, Dan Smith wrote: > >>>>> > >>>>> We don't have a membership gradle module, just a package. We're > adding this > >>>>> to geode-core. > >>>>> > >>>>> For a little more context - we are thinking about refactoring > membership > >>>>> (and/or maybe some other pieces) into separate gradle modules - > proposal > >>>>> forthcoming! However, as a first step we need to untangle those > pieces of > >>>>> code from the rest of geode-core. Rather than creating some long > lived > >>>>> branch we can incrementally untangle the code a piece at a time, on > >>>>> develop. Having a way to track progress and enforce the direction of > >>>>> dependencies on the way to a separate gradle module will help with > that. > >>>>> > >>>>> -Dan > >>>>> > >>>>>> On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett > wrote: > >>>>>> > >>>>>> Are you adding this dependency to just the membership module? I am > cool > >>>>>> with that. > >>>>>> > >>>>>>> On Jun 20, 2019, at 2:39 PM, Dan Smith wrote: > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> Bill, Ernie, and I would like to add a new (apache licensed) test > >>>>>>> dependency to geode-core - https://github.com/TNG/ArchUnit. This > is a > >>>>>> tool > >>>>>>> that lets you write tests that make assertions about the > >>>>>> interdependencies > >>>>>>> of your code - for example enforcing that package A does not > depend on > >>>>>>> package B. > >>>>>>> > >>>>>>> Initially we intend to add some tests about what parts of the > system the > >>>>>>> org.apache.geode.distributed.internal.membership package depends > on, with > >>>>>>> an eye towards making that code more independently testable > (proposal on > >>>>>>> that coming soon!). > >>>>>>> > >>>>>>> Does anyone have an issue with adding this test dependency? > >>>>>>> > >>>>>>> -Dan > > > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] what region types to support in the new management rest api
the regions in question is the > > >>>> cluster. > > >>>>> So > > >>>>>> these regions would be created on servers. > > >>>>>> So, for example, does anyone see a need to create PROXY regions on > > >>> the > > >>>>>> server? Even if we did not support them on the server, they would > > >>> still > > >>>>> be > > >>>>>> supported on clients. > > >>>>>> > > >>>>>> > > >>>>>> On Mon, Aug 19, 2019 at 4:26 PM Jinmei Liao > > >>> wrote: > > >>>>>> > > >>>>>>> Region type (in another word Region shortcut) defines a set of > > >>>>> attributes > > >>>>>>> for a region. These are the list of region types we have: > > >>>>>>> > > >>>>>>> LOCAL, > > >>>>>>> LOCAL_PERSISTENT, > > >>>>>>> LOCAL_HEAP_LRU, > > >>>>>>> LOCAL_OVERFLOW, > > >>>>>>> LOCAL_PERSISTENT_OVERFLOW, > > >>>>>>> > > >>>>>>> PARTITION, > > >>>>>>> PARTITION_REDUNDANT, > > >>>>>>> PARTITION_PERSISTENT, > > >>>>>>> PARTITION_REDUNDANT_PERSISTENT, > > >>>>>>> PARTITION_OVERFLOW, > > >>>>>>> PARTITION_REDUNDANT_OVERFLOW, > > >>>>>>> PARTITION_PERSISTENT_OVERFLOW, > > >>>>>>> PARTITION_REDUNDANT_PERSISTENT_OVERFLOW, > > >>>>>>> PARTITION_HEAP_LRU, > > >>>>>>> PARTITION_REDUNDANT_HEAP_LRU, > > >>>>>>> > > >>>>>>> REPLICATE, > > >>>>>>> REPLICATE_PERSISTENT, > > >>>>>>> REPLICATE_OVERFLOW, > > >>>>>>> REPLICATE_PERSISTENT_OVERFLOW, > > >>>>>>> REPLICATE_HEAP_LRU, > > >>>>>>> > > >>>>>>> REPLICATE_PROXY, > > >>>>>>> PARTITION_PROXY, > > >>>>>>> PARTITION_PROXY_REDUNDANT, > > >>>>>>> > > >>>>>>> In region management rest api, especially in PCC world, we are > > >>>>> wondering > > >>>>>>> 1) should we allow users to create LOCAL* regions through > > >>> management > > >>>>> rest > > >>>>>>> api? > > >>>>>>> 2) should we allow users to create *PROXY regions through > > >>> management > > >>>>> rest > > >>>>>>> api? > > >>>>>>> 3) for the rest of the PARTITION* and REPLICATE* types, should we > > >>>>> strive > > >>>>>> to > > >>>>>>> keep the region type list the same as before, or only keep the > > >> type > > >>>> as > > >>>>>>> REPLICATE/PARTITION, but use other properties like > > >> "redundantCopy" > > >>>> and > > >>>>>>> "evictionAction" to allow different permutations of region > > >>>> attributes? > > >>>>>>> > > >>>>>>> comments appreciated! > > >>>>>>> -- > > >>>>>>> Cheers > > >>>>>>> > > >>>>>>> Jinmei > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >>> > > >>> -- > > >>> Cheers > > >>> > > >>> Jinmei > > >>> > > >> > > > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] GEODE-7241 - make Jar not War?
Just incase here is the docs on pushing the war: https://geode.apache.org/docs/guide/16/tools_modules/pulse/pulse-hosted.html On Wed, Sep 25, 2019 at 9:53 AM Jacob Barrett wrote: > > > > On Sep 25, 2019, at 9:33 AM, Dan Smith wrote: > > > > +1 to making them .GWAR instead :) > > Ok I think this constitutes consensus on GWAR! ;) > -- Charlie Black | cbl...@pivotal.io
Re: Proposal of new config property "ssl-server-name-extension"
I have read the e-mail and the ticket I am not sure how this field is going to be used. Maybe you can expand on the intent of this field. >From the property "ssl-server-name-extension" it feels like we are intending to correlate with something presented in the SSL certificate. It would be great if that was explained plainly for the reader in more detail. For now I can only -1. Charlie On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac wrote: > Hi geode dev, > > as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414 > we would like to introduce new config property "ssl-server-name-extension". > > This property will contain generic string, which will be added as Server > Name Indication (SNI) parameter to Client Hello message. > > Do you agree with this proposal? > > Thanks, > Mario > -- Charlie Black | cbl...@pivotal.io
Re: Odg: Proposal of new config property "ssl-server-name-extension"
The SSL handshake is done *before* the Geode handshake.So additions to the Geode handshake protocol will not affect SSL connections since the secure socket connection has already been negotiated and the Geode handshake is encrypted. Charlie On Tue, Nov 19, 2019 at 9:06 AM Mario Ivanac wrote: > Hi all, > > this proposal and ticket are result of mail discussion "Special > certificates for multisite": > > > https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3-40-253Cdev.geode.apache.org-253E&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=PjLj2CJYNHbQUiMKrd-FKMqwbuxVERJifxQWpM4HM8k&e=> > > > BR, > Mario > -- > *Šalje:* Charlie Black > *Poslano:* 19. studenog 2019. 17:24 > *Prima:* dev@geode.apache.org > *Predmet:* Re: Proposal of new config property "ssl-server-name-extension" > > I have read the e-mail and the ticket I am not sure how this field is going > to be used. Maybe you can expand on the intent of this field. > > From the property "ssl-server-name-extension" it feels like we are > intending to correlate with something presented in the SSL certificate. > It would be great if that was explained plainly for the reader in more > detail. > > For now I can only -1. > > Charlie > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac > wrote: > > > Hi geode dev, > > > > as a part of solution for > https://issues.apache.org/jira/browse/GEODE-7414 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D7414&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=4h7HHiRlRX_Cw8mVGuVfzHgfUbKul07BjaV1CVE3_H8&e=> > > we would like to introduce new config property > "ssl-server-name-extension". > > > > This property will contain generic string, which will be added as Server > > Name Indication (SNI) parameter to Client Hello message. > > > > Do you agree with this proposal? > > > > Thanks, > > Mario > > > > > -- > Charlie Black | cbl...@pivotal.io > -- Charlie Black | cbl...@pivotal.io
Re: Odg: Odg: Proposal of new config property "ssl-server-name-extension"
Sorry - I had sent the e-mail to Mario directly. Also thanks for hanging in there with me through this. The ClientHello message is what is throwing me.As long as the SNI behaves like the extension to the standard I am fine.Meaning if "openssl s_client -connect server:port -servername servername.com" returns the right stuff we are fine. Note: I might not have all the options right in the openssl command, but -servername enables SNI. With that in mind I am + 1 on this. Charlie On Tue, Nov 19, 2019 at 12:00 PM Mario Ivanac wrote: > Hi, > > as described before: > > This property will contain generic string, which will be added as Server > Name Indication (SNI) parameter to ClientHello message. > ClientHello message is part of SSL handshake. > > Mario > ---------- > *Šalje:* Charlie Black > *Poslano:* 19. studenog 2019. 18:20 > *Prima:* Mario Ivanac > *Kopija:* dev@geode.apache.org > *Predmet:* Re: Odg: Proposal of new config property > "ssl-server-name-extension" > > The SSL handshake is done *before* the Geode handshake.So additions > to the Geode handshake protocol will not affect SSL connections since the > secure socket connection has already been negotiated and the Geode > handshake is encrypted. > > Charlie > > On Tue, Nov 19, 2019 at 9:06 AM Mario Ivanac > wrote: > > Hi all, > > this proposal and ticket are result of mail discussion "Special > certificates for multisite": > > > https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3-40-253Cdev.geode.apache.org-253E&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=PjLj2CJYNHbQUiMKrd-FKMqwbuxVERJifxQWpM4HM8k&e=> > > > BR, > Mario > -- > *Šalje:* Charlie Black > *Poslano:* 19. studenog 2019. 17:24 > *Prima:* dev@geode.apache.org > *Predmet:* Re: Proposal of new config property "ssl-server-name-extension" > > I have read the e-mail and the ticket I am not sure how this field is going > to be used. Maybe you can expand on the intent of this field. > > From the property "ssl-server-name-extension" it feels like we are > intending to correlate with something presented in the SSL certificate. > It would be great if that was explained plainly for the reader in more > detail. > > For now I can only -1. > > Charlie > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac > wrote: > > > Hi geode dev, > > > > as a part of solution for > https://issues.apache.org/jira/browse/GEODE-7414 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D7414&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=4h7HHiRlRX_Cw8mVGuVfzHgfUbKul07BjaV1CVE3_H8&e=> > > we would like to introduce new config property > "ssl-server-name-extension". > > > > This property will contain generic string, which will be added as Server > > Name Indication (SNI) parameter to Client Hello message. > > > > Do you agree with this proposal? > > > > Thanks, > > Mario > > > > > -- > Charlie Black | cbl...@pivotal.io > > > > -- > Charlie Black | cbl...@pivotal.io > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] - Move gfsh into its own submodule
this proposal == awesome sauce +1 On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton wrote: > +1 > > Do we want to restart from my lazy POC from a few months ago? > > On Fri, Nov 22, 2019, 08:40 Jens Deppe wrote: > > > Hello All, > > > > We'd like to propose moving gfsh and all associated commands into its own > > gradle submodule (implicitly thus also producing a separate maven > > artifact). The underlying intent is to decouple geode core from any > Spring > > dependencies. > > > > The proposal is outlined here: > > > > > https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project > > > > Please provide feedback for this proposal *on this email thread* and not > in > > the comment section of the proposal page. > > > > The deadline for this proposal will be Monday, December 2. > > > > Thanks in advance for feedback / comments. > > > > --Jens & Patrick > > > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] - Move gfsh into its own submodule
Just to see if the refactor happens by itself... +200 On Fri, Nov 22, 2019 at 3:10 PM Alexander Murmann wrote: > +1 > > If we get to 200, the refactor implements itself, right? > > On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh wrote: > > > +1 > > I think we are now at +114 thanks to jinmei's 100 ;-) > > > > > > On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl wrote: > > > > > +1 > > > > > > On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag wrote: > > > > > > > +1 > > > > > > > > On Fri, Nov 22, 2019 at 12:51 PM Charlie Black > > > wrote: > > > > > > > > > this proposal == awesome sauce > > > > > > > > > > +1 > > > > > > > > > > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton < > > rhough...@pivotal.io > > > > > > > > > wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > Do we want to restart from my lazy POC from a few months ago? > > > > > > > > > > > > On Fri, Nov 22, 2019, 08:40 Jens Deppe > > wrote: > > > > > > > > > > > > > Hello All, > > > > > > > > > > > > > > We'd like to propose moving gfsh and all associated commands > into > > > its > > > > > own > > > > > > > gradle submodule (implicitly thus also producing a separate > maven > > > > > > > artifact). The underlying intent is to decouple geode core from > > any > > > > > > Spring > > > > > > > dependencies. > > > > > > > > > > > > > > The proposal is outlined here: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project > > > > > > > > > > > > > > Please provide feedback for this proposal *on this email > thread* > > > and > > > > > not > > > > > > in > > > > > > > the comment section of the proposal page. > > > > > > > > > > > > > > The deadline for this proposal will be Monday, December 2. > > > > > > > > > > > > > > Thanks in advance for feedback / comments. > > > > > > > > > > > > > > --Jens & Patrick > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Charlie Black | cbl...@pivotal.io > > > > > > > > > > > > > > > -- Charlie Black | cbl...@pivotal.io
Proposals - Request For Comments (RFC) process
Just as a reminder we do have a light weight process for handling changes in "public" areas like configuration, monitoring, command line tools, etc. So as we get close to proposing changing something for the better we might want to make sure we are following the process to ensure we are doing the right thing. The Apache Geode Improvement Process. https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process Charlie -- Charlie Black | cbl...@pivotal.io
Re: WAN replication issue in cloud native environments
Alberto, Something else to think about SNI based routing. I believe Mario might be working on adding SNI to Geode - he at least had a proposal that he e-mailed out. Basics are the destination host is in the SNI field and the proxy can inspect and route the request to the right service instance. Plus we have the option to not terminate the SSL at the proxy. Full disclosure - I haven't tried out SNI based routing myself and it is something that I thought could work as I was reading about it. From the whiteboard I have done I think this will do ingress and egress just fine. Potentially easier then port mapping and `hostname for clients` playing around. Just something to think about. Charlie On Wed, Dec 4, 2019 at 3:19 AM Alberto Bustamante Reyes wrote: > Hi Jacob, > > Yes,we are using LoadBalancer service type. But note the problem is not > the transport layer but on Geode as GW senders are complaining > “sender-2-parallel : Could not connect due to: There are no active > servers.” when one of the servers in the receiving cluster is killed. > > So, there is still one server alive in the receiving cluster but GW sender > does not know it and the locator is not able to inform about its existence. > Looking at the code it seems internal data structures (maps) holding the > profiles use object whose equality check relies only on hostname and port. > This makes it impossible to differentiate servers when the same > “hostname-for-senders” and port are used. When the killed server comes back > up, the locator profiles are updated (internal map back to size()=1 > although 2+ servers are there) and GW senders happily reconnect. > > The solution with the Geode as-is would be to expose each GW receiver on a > different port outside of k8s cluster, this includes creating N Kubernetes > services for N GW receivers in addition to updating the service mesh > configuration (if it is used, firewalls etc…). Declarative nature of > kubernetes means we must know the ports in advance hence start-port and > end-port when creating each GW receiver must be equal and we should have > some well-known > algorithm when creating GW receivers across servers. For example: server-0 > port 5000, server-1 port 5001, server-2 port 5002 etc…. So, all GW > receivers must be wired individually and we must turn off Geode’s random > port allocation. > > But we are exploring the possibility for Geode to handle this cloud-native > configuration a bit better. Locators should be capable of holding GW > receiver information although they are hidden behind same hostname and port. > This is a code change in Geode and we would like to have community opinion > on it. > > Some obvious impacts with the legacy behavior would be when locator picks > a server on behalf of the client (GW sender in this case) it does so based > on the server load. When sender connects and considering all servers are > using same VIP:PORT it is load balancer that will decide where the > connection will end up, but likely not on the one selected by locator. So > here we ignore the locator instructions. Since GW senders normally do not > create huge number of connections this probably shall not unbalance cluster > too much. But this is an impact worth considering. Custom load metrics > would also be ignored by GW senders. Opinions? > > Additional impact that comes to mind is GW sender load-balance command and > how it’s execution would be affected. > > Thanks! > > Alberto B. > > > De: Jacob Barrett > Enviado: viernes, 29 de noviembre de 2019 13:06 > Para: dev@geode.apache.org > Asunto: Re: WAN replication issue in cloud native environments > > > > > On Nov 29, 2019, at 3:14 AM, Alberto Bustamante Reyes > wrote: > > > > The reason for such a setup is deploying Geode cluster on a Kubernetes > cluster where all GW receivers are reachable from the outside world on the > same VIP and port. > > Are you using LoadBalancer Service type? > > > Other kinds of configuration (different hostname and/or different port > for each GW receiver) are not cheap from OAM and resources perspective in > cloud native environments and also limit some important use-cases (like > scaling). > > If you could somehow configure host and port for sender (code modification > required) would exposing each port through the LoadBalancer be too > expensive too? > > > The problem experienced is that shutting down one server is stopping > replication to this cluster until the server is up again. We suspect this > is because Geode incorrectly assumes there are no more alive servers when > just one of them is down (since they share hostname-for-senders and port). > > Sees like at the worst case when it tries to reconnect the LB should give > it a live server and it think the single server is back up. > > -Jake > > -- Charlie Black | cbl...@pivotal.io
Re: Importance of Diffie-Hellman support in native client?
Diffie-Hellman is a valid and in-use protocol by the larger security community. On Thu, Dec 5, 2019 at 8:24 AM Blake Bender wrote: > Please see https://issues.apache.org/jira/browse/GEODE-7302. We have a > ticket to make a decision about whether or not to deprecate a couple of > properties here, and any knowledge of them has long since left the team. > Does anyone have a clue, or informed opinion, as to the importance of > keeping this support and the associated properties? > > Thanks, > > Blake > -- Charlie Black | cbl...@pivotal.io
Re: New geode-gfsh module
Reading over the docs for gfsh - I don't support removing any functionality from a top level command perspective.It should be noted that I didn't go deeper then the top level commands, there might be some sub option on some command that could be dropped or tweaked. Charlie On Mon, Dec 9, 2019 at 8:32 AM Alexander Murmann wrote: > > I imagine once the Management v2 API's are GA (and feature complete), I > don't see a reason why /gfsh/ should not be a stand alone module. It > would definitely have to be updated to use the new v2 API's, which > should not have any direct dependency on geode-core any more. > > There also is a big question here of how much of the current GFSH > functionality needs to be there to fully replace the current GFSH. Looking > at the functionality available right now, it seems like we have a very long > way ahead of us. > > On Fri, Dec 6, 2019 at 12:32 PM Owen Nichols wrote: > > > Any standalone management API or client thereof would not be able to > start > > locator or start server. For that gfsh still needs a large chunk of > > Geode. > > > > > > > On Dec 6, 2019, at 12:25 PM, Udo Kohlmeyer wrote: > > > > > > I imagine once the Management v2 API's are GA (and feature complete), I > > don't see a reason why /gfsh/ should not be a stand alone module. It > would > > definitely have to be updated to use the new v2 API's, which should not > > have any direct dependency on geode-core any more. > > > > > > On 12/6/19 10:01 AM, Jacob Barrett wrote: > > >> > > >>> On Dec 6, 2019, at 9:44 AM, Jens Deppe wrote: > > >>> > > >>> Just to be clear, this effort does *not* result in a standalone gfsh > > >>> executable/jar. > > >> Is this a future plan? > > >> > > >> > > > > > -- Charlie Black | cbl...@pivotal.io
Re: enable-time-statistics
David, I would say remove the caveat.Thanks for offering. Charlie On Fri, Jan 10, 2020 at 1:55 PM Dave Barnes wrote: > Sounds like the caveat could be dropped from the user guide. If we have > consensus on that (am I understanding correctly?), I'll initiate a JIRA > ticket. > > On Fri, Jan 10, 2020 at 1:47 PM Jacob Barrett wrote: > > > The biggest impact was in recording all the additional stats in the old > > blocking stats implementation. As of 9.8 the stats internals are mostly > > non-blocking. Enabling time stats has very little of any impact now. > > > > > On Jan 10, 2020, at 12:45 PM, Dan Smith wrote: > > > > > > I personally wouldn't be too worried about enabling time based > > statistics > > > in production. I think we segregated the time statistics because they > do > > > have to call System.nanoTime to measure the elapsed time. At one point > in > > > the history with old JDKs they called System.currentTimeMillis, which > was > > > really expensive. But now I'm not sure the nanoTime calls really have > > that > > > much of an impact compared to the rest of the processing time. > > > > > > -Dan > > > > > > > > >> On Fri, Jan 10, 2020 at 11:25 AM Mario Kevo > > wrote: > > >> > > >> Hi geode-dev, > > >> > > >> We have executed some traffic against Geode servers with time-based > > >> statistics enabled and disabled and we didn't see any performance > > >> difference. > > >> The documentation says: > > >> > > >> > > >> If you need time-based statistics, enable that. Time-based statistics > > >> require statistics sampling and archival. Example: > > >> > > >> statistic-sampling-enabled=true > > >> statistic-archive-file=myStatisticsArchiveFile.gfs > > >> enable-time-statistics=true > > >> > > >> > > >> Note: Time-based statistics can impact system performance and is not > > >> recommended for production environments. > > >> > > >> > > >> Do you know on which part this note referring to? > > >> > > >> > > >> Also we tried to enable time statistics on geode native but without > > >> success. > > >> > > >> We change in geode.properties file this parameter to true but didn't > get > > >> any additional statistics in statistics archive file. > > >> > > >> Do we need also to change something else to enable it or this is not > > >> working for geode-native? > > >> > > >> > > >> BR, > > >> > > >> Mario > > >> > > >> > > > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] Adding Google Analytics to our website
If we could add page analytics on docs and other pages that would awesome. That would allow us to create focused content blogs, videos, investment on those pages where we find the hottest views. Charlie On Wed, Apr 8, 2020 at 2:08 PM Bob Glithero wrote: > Hi All, > > Hopefully it's ok for me to add my $.02 here. While understanding where > the traffic is coming from is always helpful, it's possible to take a more > active approach to driving traffic. I also help with community marketing > at RabbitMQ (rabbitmq.com), which uses their platform to host tutorials, > best practices, and other content. I could find $$$ in my budget to help > modernize the Geode site and make it more generally useful as a content > platform for developers and others interested in the project. > > Bob > > On 4/8/20, 1:59 PM, "Alexander Murmann" wrote: > > Hi Michael, > > A few things I'd like to know and potential associated actions: > * Where do our visitors come from (referrer)? -> We might be able to > lean > in to those sources. > * Are we getting any traffic from our Twitter presence? -> If certain > tweets bring more traffic, let's do more of tweets like it! > * Some people in our community started blogging more. Are we seeing any > traffic from that? Are some topics driving more traffic than others -> > Might inform what topics or types of articles we should write more or > less > off. > > > On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske > wrote: > > > What things are we looking to learn? Without knowing what we are > > interested in learning I would be hesitant to add anything. If we > know > > what we want to learn then a conversation about analytics would be > more > > fruitful (to me at least) > > > > -michael > > > > > > On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann < > amurm...@apache.org> > > wrote: > > > > > Hi all, > > > > > > In promoting our project it might be valuable to get a better idea > of > > where > > > visitors on our website come from, what they look for and where we > lose > > > them. This should help us improve the website and learn what kind > of > > blogs > > > articles, videos etc. drive user interest to the website. > > > > > > To gain those insights I'd like to add Google Analytics (GA). > While GA > > > isn't open source, it is commonly used by other Apache projects. > Apache > > > Cassandra, Kafka, Samza and Spark all have GA trackers on their > website. > > > > > > I've heard rumors that we at some point had it on our website as > well. Is > > > this true? If so, why did we remove it? > > > > > > Thank you for your thoughts and concerns! > > > > > > > > -- Charlie Black | cbl...@pivotal.io
Re: [DISCUSS] removal of experimental Protobuf client/server interface
+1 to "removal of experimental Protobuf client/server interface" If someone offers to take on the completion of the "experimental Protobuf client/server interface" in a timely manner, then I would say hold off on removing. As for the other removal items that were brought up. Please raise those in a separate thread so we can get a proper vote on those items. Other thoughts: * After its removal if someone does want to complete the "Protobuf client/server interface" they can revive the great work out that has already been done out of version control. * A wish of completeness isn't really a statement of an intent to complete. * I am + 1 to the removal of work that is unfinished that hasn't seen progress in several years.This would make maintenance of Geode simpler. Charlie On 3/29/21, 10:33 AM, "John Blum" wrote: Correction! Although a different/separate issue, Geode's JSON document handling is incomplete at best. It does not properly handle all forms of JSON or types (e.g. Java 8 Data/Time types). From: Bruce Schuchardt Sent: Thursday, March 25, 2021 8:01 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface I worked on the protobuf client/server interface as long as anyone else but still fail to see the value in keeping it in anything but a branch unless someone is going to pick it up soon and complete it. As Dan pointed out, we already have a good interface for storing Json documents and we never got beyond that as cache values with the protobuf i/f. People want to store data in Geode in a way that works with queries, delta propagation and other advanced features. That was, and remains, the main problem for this interface. Without that it's not even as good as the current REST interface. On 3/24/21, 5:06 PM, "Jens Deppe" wrote: I was very excited when the protobuf support became available as it allowed for the fairly quick development of a Go client. (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Ccblack%40vmware.com%7C4a5f85320e78445c99db08d8f2d8b85d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526359908700570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jH7QFrF8YiIMAzywCprWBxF4Oh236gZ%2BNTISpER%2B4C0%3D&reserved=0). As Udo already mentioned, removing this functionality reduces our potential exposure to new use cases and language bindings. Just because it isn't 'feature complete' doesn't mean it isn't useful to someone. In fact, just today, somebody reached out regarding the Go binding. When considering various popular libraries/frameworks, they all have multiple bindings. Some of those are core to the library, but many are maintained separately. Having a well-defined protocol for Geode is the first step in making that possible. --Jens On 3/24/21, 1:11 PM, "Dan Smith" wrote: I also worked on the protobuf interface for a little while, although not for as long as some of the other folks commenting. I'm ok with removing it. I do see some value in leaving stalled/incomplete projects around as bait for future developers to pick up - that seems to have worked for redis ;) But if it is a maintenance burden lets drop it from develop. Someone can always pick it up from the history. If I recall correctly, one of the big incomplete parts of the project is that we hadn't figured out how to serialize user objects efficiently with this protocol. The default was to convert PDX objects to JSON. That was about as efficient as the existing REST protocol, which also uses json. -Dan From: Mike Martell Sent: Tuesday, March 23, 2021 4:53 PM To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface As the only remaining member on the CSharpDriver team, I too have an attachment to Protobuf. It’s purely technical, however, not emotional. I was truly excited about the prospects of a self-describing protocol and had hopes for a .NET client talking directly to geode without going through the C++ layer. The performance I measured doing puts/gets of a broad range of object sizes was at parity with the C++ client. I was truly surprised to see the project shelved. But I do understand we had extremely limited functionality not even close to an MVP. In hindsight, we should have put all the resources on the server side, as the client implementation was almost trivial. Mike --- Sent from Workspace ONE Boxer
Re: [DISCUSS] removal of experimental Protobuf client/server interface
+ 1 to additional repos for extensions to Geode project to keep "extensions" or bolt-ons out of the Apache Geode. I also have extensions that aren't committed to Geode.So definably a vibrant community surrounding Geode. What todo with the code: Just link to the branch/sha/fork/first addition to extensions/??? to the 2017 proposal.That would make finding the "source" and the design easier - https://cwiki.apache.org/confluence/display/GEODE/Protobuf+Protocol Note: Since this never got fully implemented - why is it in the implemented category. Anyone with wiki access want to move it to "Unknown" since it is currently abandoned. Charlie On 3/29/21, 11:55 AM, "John Blum" wrote: How hard is it to put the work like Protobuf in a separate repository (attached to Geode in some way)? I am not sure what the (Apache) procedure is. We need stop baking everything into the "core" of Apache Geode. Most things that are non-essential (meaning, they are not required for Geode to carry out its primary responsibility as a data store, also & e.g. Redis Adapter) should be an "extension" (add-on), enabled with a plugin. I fear this work would get lost if removed completely. How would new (or even existing members) know where to find this work if interested? Branches are not a good alternative. A separate repo would make the entire process (e.g. releases) easier, not unlike the Kafka connector, or even Spring Data for that matter. $0.02 -j From: Bruce Schuchardt Sent: Monday, March 29, 2021 11:41 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface That's true John, but the Protobuf i/f is using the same code as the REST server to serialize/deserialize JSON documents. It isn't any better at it. On 3/29/21, 10:33 AM, "John Blum" wrote: Correction! Although a different/separate issue, Geode's JSON document handling is incomplete at best. It does not properly handle all forms of JSON or types (e.g. Java 8 Data/Time types). From: Bruce Schuchardt Sent: Thursday, March 25, 2021 8:01 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface I worked on the protobuf client/server interface as long as anyone else but still fail to see the value in keeping it in anything but a branch unless someone is going to pick it up soon and complete it. As Dan pointed out, we already have a good interface for storing Json documents and we never got beyond that as cache values with the protobuf i/f. People want to store data in Geode in a way that works with queries, delta propagation and other advanced features. That was, and remains, the main problem for this interface. Without that it's not even as good as the current REST interface. On 3/24/21, 5:06 PM, "Jens Deppe" wrote: I was very excited when the protobuf support became available as it allowed for the fairly quick development of a Go client. (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Ccblack%40vmware.com%7C646c03df5c2248faee2808d8f2e44538%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526409520158303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=35zrg%2BcXaxHTOgAgi9dfg0VFrkdna9ccbqazay4eZFM%3D&reserved=0). As Udo already mentioned, removing this functionality reduces our potential exposure to new use cases and language bindings. Just because it isn't 'feature complete' doesn't mean it isn't useful to someone. In fact, just today, somebody reached out regarding the Go binding. When considering various popular libraries/frameworks, they all have multiple bindings. Some of those are core to the library, but many are maintained separately. Having a well-defined protocol for Geode is the first step in making that possible. --Jens On 3/24/21, 1:11 PM, "Dan Smith" wrote: I also worked on the protobuf interface for a little while, although not for as long as some of the other folks commenting. I'm ok with removing it. I do see some value in leaving stalled/incomplete projects around as bait for future developers to pick up - that seems to have worked for redis ;) But if it is a maintenance burden lets drop it from develop. Someone can always pick it up from the history. If I recall correctly, one of the big incomplete parts of the project is that we hadn't figured out how to serialize user objects efficiently with this protocol. The default was to convert PDX objects to JSON. That was about as efficient as the existing REST protocol, which also uses json. -Dan __
Re: DISCUSSION: Geode Native C++ 17 adoption
Another viewpoint is this is a library and that library can be used by older applications. So being cutting edge on the complier on the library does not increase the adoption of Geode. Agree with Alberto that users mailing lists should be consulted. Charlie From: Alberto Gomez Date: Tuesday, May 4, 2021 at 11:29 AM To: dev@geode.apache.org Subject: Re: DISCUSSION: Geode Native C++ 17 adoption Hi, Here come my two cents. To me, upgrading to C++17 is a no brainer given that C++11 is quite old and C++17 has lots of new features, performance improvements and bug fixes. The only thing that could prevent us from doing so is having lots of users that are running the native client in a platform that does not have a C++17 compiler. Which leads me to the question: should we move this discussion to the user mailing list? Alberto From: Mario Salazar de Torres Sent: Tuesday, May 4, 2021 7:45 PM To: dev@geode.apache.org Subject: Re: DISCUSSION: Geode Native C++ 17 adoption Hi everyone, Sorry for the previous email, I did send it before finishing it by mistake. Currently Geode Native uses C++11 standard. It has been quite some time since the standard was released and as of today the latest standard is C++20. As part of another discussion, some users in the community were wondering if it's the time to switch to C++17 in the Geode Native project. So, I am putting a list of pros and cons: Pros: * Several new features added: * C++14 features: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2F14%23New_language_features&data=04%7C01%7Ccblack%40vmware.com%7C99bf8329d4ed48682b2b08d90f2a8d9f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637557497738349382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rs4Pc4zW6bo2oyoaAzPDLA4gUAzm2Q8%2FRNDgLw3YxsY%3D&reserved=0 * C++17 features: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2F17%23New_language_features&data=04%7C01%7Ccblack%40vmware.com%7C99bf8329d4ed48682b2b08d90f2a8d9f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637557497738349382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dFzhj5YgERe3wtVAAbH1BukTv7Q5bcNVJNWgfPQfMlY%3D&reserved=0 * Some of the interesting features are: * Function return type deduction. * Improved constexpr functions. * Variable templates. * Generic lambdas. * Lambda capture expressions. * [[deprecated]] * Shared mutexes/locks. * std::make_unique * Nested namespace definitions. * Structured bindings. * variant. * any. * optional. Cons: * Some users might have older compilers which does not implement all C++ 17 features. Thanks, Mario. From: Mario Salazar de Torres Sent: Tuesday, May 4, 2021 7:34 PM To: dev@geode.apache.org Subject: DISCUSSION: Geode Native C++ 17 adoption Hi everyone, Currently Geode Native uses C++11 standard. It has been quite some time since the standard was released and as of today the latest standard is C++20. As part of another discussion, some users in the community were wondering if it's the time to switch to C++17 in the Geode Native project. So, I am putting a list of pros and cons: Pros: * Several new features added: * C++14 features: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2F14%23New_language_features&data=04%7C01%7Ccblack%40vmware.com%7C99bf8329d4ed48682b2b08d90f2a8d9f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637557497738359379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yeadKm2sq%2BZI3e382PQ3NlpLxyjfH0vCO7WEQyT2W%2FM%3D&reserved=0 * C++17 features: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2F17%23New_language_features&data=04%7C01%7Ccblack%40vmware.com%7C99bf8329d4ed48682b2b08d90f2a8d9f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637557497738359379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MaJ77vnuas3whxAzYCMxfFo5b2I5QJzNkSmT5iL%2FTmI%3D&reserved=0 * Some of the interesting features are: * Function return type deduction. * Improved constexpr functions. * Variable templates. - Generic lambdas. - Lambda capture expressions. - [[deprecated]] - Shared mutexes/locks. - std::make_unique C++17 - cppreference.com
[jira] [Created] (GEODE-2770) When using the REST API it is possible for the API to be accepting requests after the system has shutdown
Charlie Black created GEODE-2770: Summary: When using the REST API it is possible for the API to be accepting requests after the system has shutdown Key: GEODE-2770 URL: https://issues.apache.org/jira/browse/GEODE-2770 Project: Geode Issue Type: Improvement Components: rest (dev) Reporter: Charlie Black When using the REST API it is possible for the API to be accepting requests after the system has shutdown, -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2770) When using the REST API it is possible for the API to be accepting requests after the system has shutdown
[ https://issues.apache.org/jira/browse/GEODE-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-2770: - Description: When using the REST API it is possible for the API to be accepting requests after the system has shutdown. The shutdown sequence for the REST API should be next to the other APIs. (was: When using the REST API it is possible for the API to be accepting requests after the system has shutdown,) > When using the REST API it is possible for the API to be accepting requests > after the system has shutdown > - > > Key: GEODE-2770 > URL: https://issues.apache.org/jira/browse/GEODE-2770 > Project: Geode > Issue Type: Improvement > Components: rest (dev) > Reporter: Charlie Black > > When using the REST API it is possible for the API to be accepting requests > after the system has shutdown. The shutdown sequence for the REST API > should be next to the other APIs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
