Re: [DISCUSS] Move geode to the attic

[John Blum]

For clarification, I believe Sonatype does not allow anything to be removed 
from Maven Central once it has been published. The bits are there to stay, 
permanently, and there are no exceptions AFAIK.

-j


From: Mark Bretl 
Date: Tuesday, October 18, 2022 at 1:14 PM
To: John Blum 
Cc: dev@geode.apache.org 
Subject: Re: [DISCUSS] Move geode to the attic

⚠ External Email
Unfortunately, I do think the attic is a very real possibility.

@John Blum<mailto:jb...@vmware.com> Officially, I do not think we (Geode) or 
ASF have any type of release support policy (I searched but could not find 
anything), it is open-source for better or worse. VMware or any other company 
can pick up support if they so choose. Would have it been better for corporate 
sponsors to give support to a final release and give a proper send off? Yes, 
but we are where we are now. As for artifacts, yes they will live and remain 
as-is.

--Mark

On Tue, Oct 18, 2022 at 1:47 PM John Blum  wrote:
How does the VMware’s non-disclosed date commitment factor into this equation?

I mean, clearly the Apache Geode 1.15 release has a lifecycle and support 
timeline, even if the community (and a new PMC) does drive the project any 
further?

What happens when CVEs, or critical bugs (involving data loss) are uncovered in 
1.15, yet? What even is 1.15’s support timeline and overall lifecycle? I would 
have assumed this would minimally have been 1 year from the GA of 1.15.0.

Regarding, “Geode maven artifacts would remain available from Maven Central.”

This is absolutely critical and necessary for Apache Geode’s ecosystem of 
projects (for example, Spring for Apache Goede, such as Spring Boot and Data 
for Apache Geode) to continue to build and release against Apache Geode 
versions/bits until the end of the ecosystem project’s (e.g. SDG) support 
timeline.

-John


From: Owen Nichols 
Date: Tuesday, October 18, 2022 at 11:50 AM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] Move geode to the attic
⚠ External Email

Once moved to the attic, it sounds like:

  *   The geode github repo would become read-only (but remain world-readable 
in perpetuity).
  *   Geode would no longer be available for download on the geode download 
site or mirrors (but still available in releases tab in github).
  *   Geode maven artifacts would remain available from mavencentral.
  *   Geode homebrew formula would no longer be installable.
  *   Unsure whether apachegeode/geode docker image would remain available?
  *   Geode confluence wiki would become read-only.
  *   It sound like the user mailing list may be able to remain active?

Since no further release are possible without at least 3 active PMC members to 
provide the requisite 3 approving PMC votes, the Attic sounds like the best 
possible way to leave things.

From: Dan Smith 
Date: Tuesday, October 18, 2022 at 11:12 AM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: [DISCUSS] Move geode to the attic
⚠ External Email

Hi folks,

Unfortunately, it is time to consider moving Geode to the Apache attic. After 
VMware's announcement that it will stop contributing to Geode, we've tried in 
the last couple months to recruit additional contributors to continue 
supporting the project [1]. However, this last week there was a PMC role call 
on the private list and it appears we will only have one active PMC member 
after the VMware folks completely leave.

I think at this point the responsible thing to do is dissolve the Geode PMC and 
move the project to the attic, unless some new contributors suddenly show up. 
We need a minimum of 3 PMC members to keep the project viable.

This is not yet a vote. I'll let this discussion run this week and start a vote 
next week. I believe even if we vote to dissolve the project and move to the 
attic, the soonest that process would start would be after the November board 
meeting [2].

Thanks,
-Dan

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fd88byb42gm5wplzqwkgywg3w9vtj64drdata=05%7C01%7Cjblum%40vmware.com%7C482d2bf794ef46bd167508dab1399813%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017158176942172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eRrcPuf2Ccnkj1SIOWs%2B%2BRwjgiJch0T%2FnbYt2NMt78A%3Dreserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fd88byb42gm5wplzqwkgywg3w9vtj64dr=05%7C01%7Cjblum%40vmware.com%7C12db61d4534c407f607108dab145506c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017208525885518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=o8TqE35x4%2F%2B9wq6wpbmBAOMOS%2BbfGkDDUZrfGBFfOLI%3D=0>
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fattic.apache.org%2Fprocess.h

Re: [DISCUSS] Move geode to the attic

[John Blum]

How does the VMware’s non-disclosed date commitment factor into this equation?

I mean, clearly the Apache Geode 1.15 release has a lifecycle and support 
timeline, even if the community (and a new PMC) does drive the project any 
further?

What happens when CVEs, or critical bugs (involving data loss) are uncovered in 
1.15, yet? What even is 1.15’s support timeline and overall lifecycle? I would 
have assumed this would minimally have been 1 year from the GA of 1.15.0.

Regarding, “Geode maven artifacts would remain available from Maven Central.”

This is absolutely critical and necessary for Apache Geode’s ecosystem of 
projects (for example, Spring for Apache Goede, such as Spring Boot and Data 
for Apache Geode) to continue to build and release against Apache Geode 
versions/bits until the end of the ecosystem project’s (e.g. SDG) support 
timeline.

-John


From: Owen Nichols 
Date: Tuesday, October 18, 2022 at 11:50 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Move geode to the attic
⚠ External Email

Once moved to the attic, it sounds like:

  *   The geode github repo would become read-only (but remain world-readable 
in perpetuity).
  *   Geode would no longer be available for download on the geode download 
site or mirrors (but still available in releases tab in github).
  *   Geode maven artifacts would remain available from mavencentral.
  *   Geode homebrew formula would no longer be installable.
  *   Unsure whether apachegeode/geode docker image would remain available?
  *   Geode confluence wiki would become read-only.
  *   It sound like the user mailing list may be able to remain active?

Since no further release are possible without at least 3 active PMC members to 
provide the requisite 3 approving PMC votes, the Attic sounds like the best 
possible way to leave things.

From: Dan Smith 
Date: Tuesday, October 18, 2022 at 11:12 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Move geode to the attic
⚠ External Email

Hi folks,

Unfortunately, it is time to consider moving Geode to the Apache attic. After 
VMware's announcement that it will stop contributing to Geode, we've tried in 
the last couple months to recruit additional contributors to continue 
supporting the project [1]. However, this last week there was a PMC role call 
on the private list and it appears we will only have one active PMC member 
after the VMware folks completely leave.

I think at this point the responsible thing to do is dissolve the Geode PMC and 
move the project to the attic, unless some new contributors suddenly show up. 
We need a minimum of 3 PMC members to keep the project viable.

This is not yet a vote. I'll let this discussion run this week and start a vote 
next week. I believe even if we vote to dissolve the project and move to the 
attic, the soonest that process would start would be after the November board 
meeting [2].

Thanks,
-Dan

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fd88byb42gm5wplzqwkgywg3w9vtj64drdata=05%7C01%7Cjblum%40vmware.com%7C482d2bf794ef46bd167508dab1399813%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017158176942172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eRrcPuf2Ccnkj1SIOWs%2B%2BRwjgiJch0T%2FnbYt2NMt78A%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fattic.apache.org%2Fprocess.htmldata=05%7C01%7Cjblum%40vmware.com%7C482d2bf794ef46bd167508dab1399813%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017158176942172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PcH23xVCIid04KbsJnbJVKMZ2%2BcZyHWEov7hVsD0OjM%3Dreserved=0




⚠ External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo

[John Blum]

Personally, I believe doc is a critical component to any software project, 
especially a project like Apache Geode, and so, is the project really “complete 
“(or should thee codebase  really be frozen during a release) if the doc is not 
done or consistent yet?

Having the doc be part of the source allows the doc to be (theoretically) 
in-sync with the codebase as it evolves, as it should be. On the other hand, 
with a separate repo, it does allow corrections or other alterations to be made 
at the risk of growing inconsistency, which is a huge impediment IMO. In 
Asciidoc, doc can even be based on the source in part (e.g. interfaces).

Ideally, I don’t see code and doc being separate or even fundamentally 
different.

This sounds more like a process problem and a workaround to a broken process, 
to me.

$0.02
-John


From: Dave Barnes 
Date: Tuesday, June 14, 2022 at 12:15 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
⚠ External Email

I'd like to move the doc sources for the Geode User Guide from the code
repo 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeodedata=05%7C01%7Cjblum%40vmware.com%7Cb6ae14ef841e416fb22208da4e3a2bb4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637908308999514633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=vWegMzha9uIc8JMMAYhgxU20V9beAoSbAFOK5aORAfc%3Dreserved=0)
 to a separate geode-docs repo.

The primary reason is to allow docs to cycle at their own rate, rather than
in lock-step with the code. The present arrangement causes problems during
releases, when code is frozen (including doc sources) to prepare a release
candidate. This is exactly the time when critical last-minute doc changes
are needed, but such changes are forbidden due to the code freeze.

I have participated in the Geode project since its inception, and can
confidently state that this conflict arises with nearly every Geode
release. Setting up the docs in a separate repo would alleviate this
regularly-recurring, counter-intuitive situation.

Of note: The docs directories and toolset are almost entirely independent
of directories and tools needed for code development and release, so
removal of the doc sources from the Geode code repo should be painless for
developers.

Observations and opinions welcome...

Dave Barnes



⚠ External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: [PROPOSAL] RFC for migrating from springfox to springdoc

[John Blum]

Spring Data for Apache Geode (and the upcoming Spring Data for VMware Tanzu 
GemFire) very much depends on and uses the Management REST API.


From: Jinmei Liao 
Date: Thursday, May 5, 2022 at 5:40 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc
>Does this inactivity demonstrate maturity (i.e. maybe we should remove the 
>@Experimental annotation) or does it indicate a failed or abandoned experiment
Neither, I believe k8s is using the feature, but the inactivity simply means we 
haven’t allocated people to work on it.

From: Owen Nichols 
Date: Thursday, May 5, 2022 at 5:12 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc
It would be great to make the switch to springdoc.  If you are willing, go for 
it!

Slightly outside the scope of this RFC:
Swagger was added as part of the @Experimental manageability REST API [1] and 
is used to generate API docs for each minor [2]. It looks like the API hasn’t 
changed much between the last few minors.  Does this inactivity demonstrate 
maturity (i.e. maybe we should remove the @Experimental annotation) or does it 
indicate a failed or abandoned experiment (i.e. should we consider entirely 
removing all code for this feature, following the same reasoning cited for 
removing @Experimental protobuf [3] and @Experimental redis [4])?

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCluster%2BManagement%2BServicedata=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6wJx8xiZxyRJc%2B0HbOzUPn8R5b8ENNWGkpaxxXEPO9I%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCluster%2BManagement%2BService%2BRest%2BAPIdata=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=wtybzPIBgRo7cf4g4vqZPtGZWsmzNXQu%2BfdxnEjHEv8%3Dreserved=0
[3] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fzt7jphfjqqgkgjn010clq2wqo9vv2z6ndata=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=JJWpKdG8JTnhy8cBz0hY5UHXLXO6IgdjAkoR5wHky2k%3Dreserved=0
[4] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F7m23h9r0tf536g414bwjsplqh1qv2ct0data=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0ZS1ASrd2ajzbl%2BKlQv6ZN3VZxVSNLGlKH1PTpmPZwA%3Dreserved=0

From: Alexander Murmann 
Date: Thursday, May 5, 2022 at 4:09 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc
Thanks for your proposal, Patrick!

I wonder if this even warrants a proposal over a PR. There seems to be neither 
a downside nor a realistic alternative.

From: Patrick Johnson 
Sent: Thursday, May 5, 2022 13:39
To: dev@geode.apache.org 
Subject: [PROPOSAL] RFC for migrating from springfox to springdoc

Hello devs!

Please review this RFC: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FMigration%2Bfrom%2Bspringfox%2Bto%2Bspringdocdata=05%7C01%7Cjblum%40vmware.com%7C7a1c093ee04a4f6d605b08da2ef8f57d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873944059569082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=zYIOaB9SCVLjKtK9QPBJosP1XK82zazcCo7f17Sq%2FcA%3Dreserved=0
 on migrating from springfox to springdoc for our swagger needs and provide any 
feedback you have.

Review period until Friday, May 13th.

—Patrick Johnson

Re: Update the build to use Gradle 7.4

[John Blum]

Hi Ryan-

Nice work on the Gradle 7.4 upgrade!

I know first-hand how challenging this effort is since I am (currently) going 
through the same exercise with all the Spring for Apache Geode projects.

In fact, minimally, Gradle 7.3 is required to build with Java 17 [1].

Be careful when switching pre-Gradle 7 "compile" dependencies to "compileOnly" 
as those dependencies won't show up on the runtime classpath. In certain cases, 
those dependencies may need to be "implementation" scoped, or even "api" scoped 
if the Geode module is a "Java Library" (declared by the Java Library Gradle 
Plugin [2]), and the module's declared dependencies should be exported as part 
of the library API. geode-core appropriately has several of these (for example, 
here
 [3] and 
here
 [4]; this 
dependency
 [5] arguably should not be exposed as it is an "implementation" detail and not 
strictly something users require to program against the Geode  (core) API; A 
good example of "compileOnly" dependencies can be seen 
here
 [6]).

Some of the other scope names have changed as well, e.g. "runtime" to 
"runtimeOnly".

Anyway, more information about dependency scopes can be found 
here
 [7] and 
here
 [8].

Regards,
John


[1] https://docs.gradle.org/7.3.3/release-notes.html
[2] https://docs.gradle.org/current/userguide/java_library_plugin.html
[3] 
https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L248
[4] 
https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L260
[5] 
https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L190
[6] 
https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/build.gradle#L203-L205
[7] 
https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management
[8] 
https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation


From: Ryan Gardner 
Sent: Wednesday, February 9, 2022 7:32 AM
To: dev@geode.apache.org 
Subject: Update the build to use Gradle 7.4

Hello,

Up-front disclaimer: I'm not a Gradle expert - but I spent a little time
poking around at what it would take to upgrade the build to go from Gradle
6.8 -> Gradle 7.4

Previous efforts to clean up Gradle 7 deprecation warnings made it fairly
straightforward - in the end it seems there were only a few changes needed.

- An internal gradle class for the temporary file creation changed it's
package location in Gradle 7
- A couple places had references to the now-removed "compile" classpath and
needed to be replaced with "compileOnly"
- Gradle 7 gets upset about tasks that have implicit dependencies between
them - some of the tasks such as the combined report generation needed to
have a "dependsOn" added to it
- The Geode build has a custom version of the "DefaultTaskExecutor" -
Gradle made some minor changes to the DefaultTaskExecutor in version 7.4. I
made those same changes in the RepeatedTaskExecutor

On my local machine the build runs the same as it does on the 6.8 version -
there are some tests that fail due to bind exceptions.

I just created a draft pull request - like I mentioned before, I'm not the
world's leading expert in Gradle so there may be a better way to make some
of the same kind of changes. I created a draft pull request so that it
might at least serve as a starting point when someone else wants to take a
look at this.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7351data=04%7C01%7Cjblum%40vmware.com%7C0a5b49c75996410c6b9508d9ebe17e68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637800175994899287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=YYkUU3PJFxkj57VnQsWzvA%2ByElUqFTjYlXEaB5NvMqk%3Dreserved=0

I didn't see a JIRA issue directly associated with this, it's sort of
related to GEODE-9161 

 since
it gets rid of the deprecation warnings.

Hope it's helpful,

Ryan

Re: [VOTE] Apache Geode 1.14.0.RC2

[John Blum]

+1

Spring Data for Apache Geode (SDG) Q/2.6 builds successfully with Apache Geode 
1.14.0 (RC2).

From: Jianxia Chen 
Sent: Thursday, September 2, 2021 2:49 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.14.0.RC2

+1

* Use binary distribution to create region, put, get and persistent restart
* Verified the pipelines

On Tue, Aug 31, 2021 at 5:37 PM nabarun nag  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.14.0.RC2.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline: Please note that this is an expedited voting process
> 3PM PST Thur, September 02 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.14.0.RC2
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.0data=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952892443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JvgXYkpt1Nj3XtQtp4xzsuw%2B51IYRisV9iNZZx%2FHhfg%3Dreserved=0
>
> Source and binary distributions:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.0.RC2%2Fdata=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lCylDwTq8wfMMvPPu9DFre0UjT5JVXHbbLeep9aphRE%3Dreserved=0
>
> Maven staging repo:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1098data=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Xxwcolt%2BOEtMaFUwlopB52fitD2f0z60iD2SJ%2BHo7Nk%3Dreserved=0
>
> GitHub:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=zZzHap08tfsStCOW1ybaFHdqxVsTWLcuVWxKy81jDa4%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1Fqzdxs0pbPo%2BY%2BiSgKmUxzOltkt1gvpET0WP8R6fBA%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m%2FDae%2B9kQlXDJ636WuAhBgO%2F1c7Wt0e4Az37ZA7uziA%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UtWkPTFWSa9lWsyJs4fDWSZKloqYL7q3hkBEQZZ0FTk%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Pzp5ithaEtUOyInGXz2nj%2BgAU53UsWczlmZbbXiq6kk%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-rcdata=04%7C01%7Cjblum%40vmware.com%7C34f1369b68714428a7b808d96e5b9888%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637662161952902439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=c%2BL3dQS8Q5yNXEnqYcEZLUEzygd3gvfcryGgKARrt%2Fg%3Dreserved=0
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> 

Re: JDK 16 Support?

[John Blum]

Repository(PartitionedRepositoryManager.java:151)
at 
org.apache.geode.cache.lucene.internal.PartitionedRepositoryManager.lambda$computeRepository$1(PartitionedRepositoryManager.java:170)
at 
java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1916)
at 
org.apache.geode.cache.lucene.internal.PartitionedRepositoryManager.computeRepository(PartitionedRepositoryManager.java:162)
at 
org.apache.geode.cache.lucene.internal.LuceneBucketListener.lambda$afterPrimary$0(LuceneBucketListener.java:40)


____
From: John Blum 
Sent: Monday, May 10, 2021 11:19 AM
To: dev@geode.apache.org ; u...@geode.apache.org 

Subject: Re: JDK 16 Support?

Thanks Bill (everyone) for the information.

For clarification, SDG primarily builds on Apache Geode GA versions (e.g. 
1.13.2). This is true for 3rd party libs as well. We rarely, if ever, use 
milestones or release candidates, much less snapshots, for any non-controlled 
dependency, in the mainline. This is necessary to always keep SD[G] in a 
releasable state when/if needed (e.g. critical CVE).

As an exception, we additionally build SDG (master-next) on the most recent 
1.14 snapshots (i.e. mainline version +1, e.g. main is set to 1.13 [1] and 
master-next is set to 1.14 [2], even if an Apache Geode 1.15 branch were cut) 
to prepare SDG for the next version when it becomes GA so we are ready to 
upgrade to that version and get it into a release ASAP.

All of this is to say, any changes to support JDK 16 or above, would need to be 
either in a Geode 1.13.3+ release and/or 1.14 when available for SDG to be 
fully JDK 16+ compatible.

Thx,
-j


[1] 
https://github.com/spring-projects/spring-data-geode/blob/main/spring-data-geode/pom.xml#L23<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspring-projects%2Fspring-data-geode%2Fblob%2Fmain%2Fspring-data-geode%2Fpom.xml%23L23=04%7C01%7Cjblum%40vmware.com%7C9998d26cebc24240bd8e08d913e024d9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637562675683129228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Xtda7TByM5JmN1gvuCPNMRL3fJTcYrd6tWCzC5lTc60%3D=0>
[2] 
https://github.com/spring-projects/spring-data-geode/blob/master-next/spring-data-geode/pom.xml#L23<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspring-projects%2Fspring-data-geode%2Fblob%2Fmaster-next%2Fspring-data-geode%2Fpom.xml%23L23=04%7C01%7Cjblum%40vmware.com%7C9998d26cebc24240bd8e08d913e024d9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637562675683139226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=cMjYaCp4ISdqwVyU8GionRK7eLEn3xQv786lAw%2F%2BfTY%3D=0>


From: Bill Burcham 
Sent: Monday, May 10, 2021 10:54 AM
To: dev@geode.apache.org 
Cc: u...@geode.apache.org 
Subject: Re: JDK 16 Support?

John, this doesn't speak to the general question of JDK version support. But 
the particular stack trace you showed makes me wonder if the fix for GEODE-9081 
(landed on 3/30/21 on the develop branch) might get you a little bit further. 
That commit 7ac9d7e4f0d04c99298067ca0611d9326e96d9cf eliminated the reflective 
field access in favor of some simpler down-casting.

On Wed, May 5, 2021 at 9:06 AM John Blum 
mailto:jb...@vmware.com>> wrote:
Hi Anthony-

Thank you for the quick reply.

The Spring Data Team is currently looking ahead towards Java 16 when building 
and running Spring Data examples to get a sense for what works and what 
doesn't, now that Java 16 is GA along with anticipation for users with 
questions or problems.

Spring Framework itself aligns and is based on LTS Java versions only, 
currently Java 8 with Spring Framework 5.  Spring Framework 6 will likely move 
the baseline to Java 11 or possibly even Java 17, we are not sure which yet.

Just want to share our findings and give advanced notice.

Thanks,
John


From: Anthony Baker mailto:bak...@vmware.com>>
Sent: Wednesday, May 5, 2021 8:14 AM
To: u...@geode.apache.org<mailto:u...@geode.apache.org> 
mailto:u...@geode.apache.org>>
Cc: geode mailto:dev@geode.apache.org>>
Subject: Re: JDK 16 Support?

Thanks for reporting this John.  The next LTS version of Java (17) is due later 
this year.  I think Geode needs to at least support every LTS version of Java 
and clearly we would need to fix errors like this. Do you see a need to support 
Java 16 now?

Anthony


On May 5, 2021, at 7:57 AM, John Blum 
mailto:jb...@vmware.com><mailto:jb...@vmware.com<mailto:jb...@vmware.com>>>
 wrote:

What is the plan to support Java 16 for Apache Geode?  Timeframe?

Running Apache Geode on a Java 16 Runtime produces errors like the following:


- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte 
buffer
-  at 
org.apache.geode.internal.net<https://nam04.safelinks.protection.outlook.com/?url=h

Re: JDK 16 Support?

[John Blum]

Thanks Bill (everyone) for the information.

For clarification, SDG primarily builds on Apache Geode GA versions (e.g. 
1.13.2). This is true for 3rd party libs as well. We rarely, if ever, use 
milestones or release candidates, much less snapshots, for any non-controlled 
dependency, in the mainline. This is necessary to always keep SD[G] in a 
releasable state when/if needed (e.g. critical CVE).

As an exception, we additionally build SDG (master-next) on the most recent 
1.14 snapshots (i.e. mainline version +1, e.g. main is set to 1.13 [1] and 
master-next is set to 1.14 [2], even if an Apache Geode 1.15 branch were cut) 
to prepare SDG for the next version when it becomes GA so we are ready to 
upgrade to that version and get it into a release ASAP.

All of this is to say, any changes to support JDK 16 or above, would need to be 
either in a Geode 1.13.3+ release and/or 1.14 when available for SDG to be 
fully JDK 16+ compatible.

Thx,
-j


[1] 
https://github.com/spring-projects/spring-data-geode/blob/main/spring-data-geode/pom.xml#L23
[2] 
https://github.com/spring-projects/spring-data-geode/blob/master-next/spring-data-geode/pom.xml#L23


From: Bill Burcham 
Sent: Monday, May 10, 2021 10:54 AM
To: dev@geode.apache.org 
Cc: u...@geode.apache.org 
Subject: Re: JDK 16 Support?

John, this doesn't speak to the general question of JDK version support. But 
the particular stack trace you showed makes me wonder if the fix for GEODE-9081 
(landed on 3/30/21 on the develop branch) might get you a little bit further. 
That commit 7ac9d7e4f0d04c99298067ca0611d9326e96d9cf eliminated the reflective 
field access in favor of some simpler down-casting.

On Wed, May 5, 2021 at 9:06 AM John Blum 
mailto:jb...@vmware.com>> wrote:
Hi Anthony-

Thank you for the quick reply.

The Spring Data Team is currently looking ahead towards Java 16 when building 
and running Spring Data examples to get a sense for what works and what 
doesn't, now that Java 16 is GA along with anticipation for users with 
questions or problems.

Spring Framework itself aligns and is based on LTS Java versions only, 
currently Java 8 with Spring Framework 5.  Spring Framework 6 will likely move 
the baseline to Java 11 or possibly even Java 17, we are not sure which yet.

Just want to share our findings and give advanced notice.

Thanks,
John


From: Anthony Baker mailto:bak...@vmware.com>>
Sent: Wednesday, May 5, 2021 8:14 AM
To: u...@geode.apache.org<mailto:u...@geode.apache.org> 
mailto:u...@geode.apache.org>>
Cc: geode mailto:dev@geode.apache.org>>
Subject: Re: JDK 16 Support?

Thanks for reporting this John.  The next LTS version of Java (17) is due later 
this year.  I think Geode needs to at least support every LTS version of Java 
and clearly we would need to fix errors like this. Do you see a need to support 
Java 16 now?

Anthony


On May 5, 2021, at 7:57 AM, John Blum 
mailto:jb...@vmware.com><mailto:jb...@vmware.com<mailto:jb...@vmware.com>>>
 wrote:

What is the plan to support Java 16 for Apache Geode?  Timeframe?

Running Apache Geode on a Java 16 Runtime produces errors like the following:


- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte 
buffer
-  at 
org.apache.geode.internal.net<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Forg.apache.geode.internal.net%2F=04%7C01%7Cjblum%40vmware.com%7C13ab03b743c34ea809cf08d913dcae47%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637562660832129959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=0s0zAIHOunv9GSNPbfu%2BelBHAGU6vpaYpC864A9%2FjNA%3D=0>.BufferPool.getPoolableBuffer(BufferPool.java:346)
-  at 
org.apache.geode.internal.net<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Forg.apache.geode.internal.net%2F=04%7C01%7Cjblum%40vmware.com%7C13ab03b743c34ea809cf08d913dcae47%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637562660832139960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Mmudm8ZO%2BkpGzK0lnhzeI%2BNBsOgZEpINeNiAF5MeWx4%3D=0>.BufferPool.releaseBuffer(BufferPool.java:310)
-  at 
org.apache.geode.internal.net<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Forg.apache.geode.internal.net%2F=04%7C01%7Cjblum%40vmware.com%7C13ab03b743c34ea809cf08d913dcae47%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637562660832139960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Mmudm8ZO%2BkpGzK0lnhzeI%2BNBsOgZEpINeNiAF5MeWx4%3D=0>.BufferPool.releaseSenderBuffer(BufferPool.java:213)
-  at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
-  at 
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
-  at 
org.apache.geode.distribut

Re: JDK 16 Support?

[John Blum]

Hi Anthony-

Thank you for the quick reply.

The Spring Data Team is currently looking ahead towards Java 16 when building 
and running Spring Data examples to get a sense for what works and what 
doesn't, now that Java 16 is GA along with anticipation for users with 
questions or problems.

Spring Framework itself aligns and is based on LTS Java versions only, 
currently Java 8 with Spring Framework 5.  Spring Framework 6 will likely move 
the baseline to Java 11 or possibly even Java 17, we are not sure which yet.

Just want to share our findings and give advanced notice.

Thanks,
John


From: Anthony Baker 
Sent: Wednesday, May 5, 2021 8:14 AM
To: u...@geode.apache.org 
Cc: geode 
Subject: Re: JDK 16 Support?

Thanks for reporting this John.  The next LTS version of Java (17) is due later 
this year.  I think Geode needs to at least support every LTS version of Java 
and clearly we would need to fix errors like this. Do you see a need to support 
Java 16 now?

Anthony


On May 5, 2021, at 7:57 AM, John Blum 
mailto:jb...@vmware.com>> wrote:

What is the plan to support Java 16 for Apache Geode?  Timeframe?

Running Apache Geode on a Java 16 Runtime produces errors like the following:


- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte 
buffer
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
-  at 
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
-  at 
org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
-  at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
-  at 
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
-  at 
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
-  at 
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
-  at 
org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
-  at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
-  at 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
-  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
-  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
-  at 
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
-  at 
org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
-  at 
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
-  at java.base/java.lang.Thread.run(Thread.java:831)
- Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible: 
module java.base does not "opens java.nio" to unnamed module @40f9161a
-  at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
-  at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
-  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
-  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
-  ... 22 common frames omitted
- 2021-04-30 14:57:13,638  INFO ributed.internal.membership.gms.Services: 606 - 
received leave request from 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001 
for 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
- 2021-04-30 14:57:13,640  INFO ributed.internal.membership.gms.Services: 617 - 
JoinLeave.processMessage(LeaveRequestMessage) invoked.  isCoordinator=true; 
isStopping=false; cancelInProgress=false
- 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler:  92 - 
Uncaught exception in thread Thread[P2P message reader f

JDK 16 Support?

[John Blum]

What is the plan to support Java 16 for Apache Geode?  Timeframe?

Running Apache Geode on a Java 16 Runtime produces errors like the following:


- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte 
buffer
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
-  at 
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
-  at 
org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
-  at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
-  at 
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
-  at 
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
-  at 
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
-  at 
org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
-  at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
-  at 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
-  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
-  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
-  at 
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
-  at 
org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
-  at 
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
-  at java.base/java.lang.Thread.run(Thread.java:831)
- Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible: 
module java.base does not "opens java.nio" to unnamed module @40f9161a
-  at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
-  at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
-  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
-  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
-  ... 22 common frames omitted
- 2021-04-30 14:57:13,638  INFO ributed.internal.membership.gms.Services: 606 - 
received leave request from 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001 
for 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
- 2021-04-30 14:57:13,640  INFO ributed.internal.membership.gms.Services: 617 - 
JoinLeave.processMessage(LeaveRequestMessage) invoked.  isCoordinator=true; 
isStopping=false; cancelInProgress=false
- 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler:  92 - 
Uncaught exception in thread Thread[P2P message reader for 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001 
shared unordered uid=1 local port=53039 remote port=64063,10,main]
- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte 
buffer
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
-  at 
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
-  at 
org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:217)
-  at 
org.apache.geode.internal.tcp.Connection.releaseInputBuffer(Connection.java:1512)
-  at org.apache.geode.internal.tcp.Connection.run(Connection.java:1495)
-  at java.base/java.lang.Thread.run(Thread.java:831)
- Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible: 
module java.base does not "opens java.nio" to unnamed module @40f9161a
-  at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
-  at 

Re: [VOTE] Requiring final keyword on every parameter and local variable

[John Blum]

Argy!  Sorry typo (corrected with surrounding ***)...


I vote  -1 for (generally) using final within constructor/method parameters and 
local variables.

While final (e.g. on instance variables) has guaranteed benefits during 
construction (e.g. initialization safety of an object used in a muti-Threaded 
context) as Kirk rightly pointed out, its non-apparent, intended use can be 
ill-conceived and ill-received outside this context.

As Jason also mentioned, which cannot be overemphasized enough, final (by 
itself) does not guarantee immutability, which is often the intention of using 
final in the first place.

While using final ensures immutability of primitive types (e.g. int, & their 
corresponding wrapper types, i.e. Integer, only because the Integer class is 
immutable to begin with) it does not ensure immutability of reference types 
(***mutable objects***), arrays or Collection types.  You can still change 
primitive arrays or arrays/Collections containing reference types, even when 
the array/Collection reference is final, regardless of whether an 
array/Collection is passed to a constructor or method. Additionally, arrays and 
Collections may contain mutable objects.

While there is some utility in using final, there are often much better 
techniques that can be applied, such as, but not limited to:

1) Strict validation and read-only use of arguments (effectively immutable).
2) Making defensive copies of arguments passed in where appropriate.
3) Limiting the scope of the (defined) variable.  E.g. Using (private) utility 
methods to limit the scope and use (processing) of the variable passed into a 
constructor or method as an argument.

Keep in mind that Java is Pass by Value, not Pass by Reference, and in some 
cases, you can use this fact to your advantage.

So, because final is not a complete solution, this is why I vote -1.

NOTE: This does not mean I don't support using final in some cases (even for 
constructor or method parameters and even local variables), just that it should 
be used judiciously, like everything else, to explicitly express intent.  And, 
most importantly, function should match intent.


-j



From: John Blum 
Sent: Wednesday, April 21, 2021 6:02 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable

I vote  -1 for (generally) using final within constructor/method parameters and 
local variables.

While final (e.g. on instance variables) has guaranteed benefits during 
construction (e.g. initialization safety of an object used in a muti-Threaded 
context) as Kirk rightly pointed out, its non-apparent, intended use can be 
ill-conceived and ill-received outside this context.

As Jason also mentioned, which cannot be overemphasized enough, final (by 
itself) does not guarantee immutability, which is often the intention of using 
final in the first place.

While using final ensures immutability of primitive types (e.g. int, & their 
corresponding wrapper types, i.e. Integer, only because the Integer class is 
immutable to begin with) it does not ensure immutability of reference types 
(immutable objects), arrays or Collection types.  You can still change 
primitive arrays or arrays/Collections containing reference types, even when 
the array/Collection reference is final, regardless of whether an 
array/Collection is passed to a constructor or method. Additionally, arrays and 
Collections may contain mutable objects.

While there is some utility in using final, there are often much better 
techniques that can be applied, such as, but not limited to:

1) Strict validation and read-only use of arguments (effectively immutable).
2) Making defensive copies of arguments passed in where appropriate.
3) Limiting the scope of the (defined) variable.  E.g. Using (private) utility 
methods to limit the scope and use (processing) of the variable passed into a 
constructor or method as an argument.

Keep in mind that Java is Pass by Value, not Pass by Reference, and in some 
cases, you can use this fact to your advantage.

So, because final is not a complete solution, this is why I vote -1.

NOTE: This does not mean I don't support using final in some cases (even for 
constructor or method parameters and even local variables), just that it should 
be used judiciously, like everything else, to explicitly express intent.  And, 
most importantly, function should match intent.


-j



From: Owen Nichols 
Sent: Wednesday, April 21, 2021 5:16 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable

Good point.  We're probably stuck on vanilla JDK8 for years more anyway.

Since this discussion seems to be mainly about personal viewing preference, I 
wonder if someone has written an IntellJ plugin that would simply render 
effectively-final variables as if they were preceded by the word "final" (for

Re: [VOTE] Requiring final keyword on every parameter and local variable

[John Blum]

I vote  -1 for (generally) using final within constructor/method parameters and 
local variables.

While final (e.g. on instance variables) has guaranteed benefits during 
construction (e.g. initialization safety of an object used in a muti-Threaded 
context) as Kirk rightly pointed out, its non-apparent, intended use can be 
ill-conceived and ill-received outside this context.

As Jason also mentioned, which cannot be overemphasized enough, final (by 
itself) does not guarantee immutability, which is often the intention of using 
final in the first place.

While using final ensures immutability of primitive types (e.g. int, & their 
corresponding wrapper types, i.e. Integer, only because the Integer class is 
immutable to begin with) it does not ensure immutability of reference types 
(immutable objects), arrays or Collection types.  You can still change 
primitive arrays or arrays/Collections containing reference types, even when 
the array/Collection reference is final, regardless of whether an 
array/Collection is passed to a constructor or method. Additionally, arrays and 
Collections may contain mutable objects.

While there is some utility in using final, there are often much better 
techniques that can be applied, such as, but not limited to:

1) Strict validation and read-only use of arguments (effectively immutable).
2) Making defensive copies of arguments passed in where appropriate.
3) Limiting the scope of the (defined) variable.  E.g. Using (private) utility 
methods to limit the scope and use (processing) of the variable passed into a 
constructor or method as an argument.

Keep in mind that Java is Pass by Value, not Pass by Reference, and in some 
cases, you can use this fact to your advantage.

So, because final is not a complete solution, this is why I vote -1.

NOTE: This does not mean I don't support using final in some cases (even for 
constructor or method parameters and even local variables), just that it should 
be used judiciously, like everything else, to explicitly express intent.  And, 
most importantly, function should match intent.


-j



From: Owen Nichols 
Sent: Wednesday, April 21, 2021 5:16 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable

Good point.  We're probably stuck on vanilla JDK8 for years more anyway.

Since this discussion seems to be mainly about personal viewing preference, I 
wonder if someone has written an IntellJ plugin that would simply render 
effectively-final variables as if they were preceded by the word "final" (for 
people that want to see finals everywhere), or a plugin to collapse unnecessary 
finals (for people that don't want to see them).

On 4/21/21, 4:36 PM, "John Blum"  wrote:

I wouldn't recommend Lombok for production code, primarily because it 
generates code. Generated code occasionally leads to unintended consequences or 
incompatibilities with newer Java versions.  Additionally, it requires as 
3rd-party dependency to gain these capabilities rather than being part of the 
Java language itself.  I'd rather Java include appropriate features for these 2 
concerns, i.e. val & var, much like Kotlin, to more succinctly express intent. 
Even though Java now has var, it is different than Kotlin's var.

I only use Lombok for testing and demoing purposes.

-j

From: Kirk Lund 
Sent: Wednesday, April 21, 2021 12:59 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable

I'm interested in 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojectlombok.org%2Fdata=04%7C01%7Cjblum%40vmware.com%7C02abefcbe3d64280ff9e08d90523f719%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546474297335201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=c5TTu5bpWjDlwMAG%2BYpG7YZduYa1oepW%2FLJ%2FvcFMx%2Fg%3Dreserved=0
 and I remember John Blum using
it on some projects. I would like to study it and do some perf testing on
it before supporting it for Geode though. In general, I don't like
generated code and it looks like at least some of the features involve
generated code -- that's the only potential downside for me.

-Kirk

On Mon, Apr 19, 2021 at 12:57 PM Owen Nichols  wrote:

> Any interest in adopting 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojectlombok.org%2Fdata=04%7C01%7Cjblum%40vmware.com%7C02abefcbe3d64280ff9e08d90523f719%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546474297345194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MPVD7jfKKmRUuanKFzysHfJJxEVY1%2FneQBUvcLbIN38%3Dreserved=0
 in Geode?  Lombok
> allow a more readable "val" vs "var" syntax instead of "final" vs "" 

Re: [VOTE] Requiring final keyword on every parameter and local variable

[John Blum]

I wouldn't recommend Lombok for production code, primarily because it generates 
code. Generated code occasionally leads to unintended consequences or 
incompatibilities with newer Java versions.  Additionally, it requires as 
3rd-party dependency to gain these capabilities rather than being part of the 
Java language itself.  I'd rather Java include appropriate features for these 2 
concerns, i.e. val & var, much like Kotlin, to more succinctly express intent. 
Even though Java now has var, it is different than Kotlin's var.

I only use Lombok for testing and demoing purposes.

-j

From: Kirk Lund 
Sent: Wednesday, April 21, 2021 12:59 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable

I'm interested in 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojectlombok.org%2Fdata=04%7C01%7Cjblum%40vmware.com%7Cebf313cf7061468b6e8508d904fff633%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546319662043634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yHceAr%2FbQtVTQAmSWxkNYkctPFP8nG6fph0QWLCRaDA%3Dreserved=0
 and I remember John Blum using
it on some projects. I would like to study it and do some perf testing on
it before supporting it for Geode though. In general, I don't like
generated code and it looks like at least some of the features involve
generated code -- that's the only potential downside for me.

-Kirk

On Mon, Apr 19, 2021 at 12:57 PM Owen Nichols  wrote:

> Any interest in adopting 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojectlombok.org%2Fdata=04%7C01%7Cjblum%40vmware.com%7Cebf313cf7061468b6e8508d904fff633%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546319662043634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yHceAr%2FbQtVTQAmSWxkNYkctPFP8nG6fph0QWLCRaDA%3Dreserved=0
>  in Geode?  Lombok
> allow a more readable "val" vs "var" syntax instead of "final" vs "" which
> could make it easier to do the right thing without "increasing visual
> noise".
>
> On 4/19/21, 12:40 PM, "Dale Emery"  wrote:
>
> My test for whether enforce a guideline in a PR review is: Would I be
> willing to automate enforcing it in CI?
>
> I am -0 on this particular guideline.
>
> IntelliJ offers two competing inspections for Java coding style:
>
>   *   Local variable or parameter can be final
>   *   Unnecessary 'final' on local variable or parameter
>
> Both of these are (I think) disabled by default in IntelliJ. And
> neither satisfies my “I’d be willing to automate enforcing it” test.
>
> Dale
>
> From: Mark Hanson 
> Date: Monday, April 19, 2021 at 11:08 AM
> To: dev@geode.apache.org 
> Subject: Re: [VOTE] Requiring final keyword on every parameter and
> local variable
> Hi Jake,
>
> I agree with everyone's point about final being a useful, I just don't
> find it useful enough to do anything manually across the code base at this
> point.
>
> I believe first in foremost in no code warnings. Intellij warns about
> variables that can be final, so I make them final as it finds them. It is
> very rare that I am writing new code at this point. I have spent the last
> year bug fixing other people's code.  From my standpoint, original intent
> is largely moot. So, for me, the question is do I go through code that is
> not mine and mark it all as final (where appropriate)? Sure, in code that I
> touch. In code the rest of the codebase, I think there are bigger fish to
> fry before we get to final.
>
> It seems like the larger portion of the consensus is to recommend that
> variables are marked final (where appropriate) as we find them or create
> them.
> That seems like the going forward approach consensus.
>
> I will be blunt though. This seems nitpicky *compared* to the number
> of code warnings there are and the fact that people are not actively fixing
> all of the warnings.
> If we don't come to the same consensus about all warnings this seems
> like painting a rusted car, sure it makes it all look the same, but does
> very little for the underlying problems. Now to undermine my own argument a
> little, I think that especially in release blockers, we want to touch as
> little code as possible, so I am flexible there.
>
> I would also like to agree with Udo about final really not being very
> good compared to Mutable and Immutable objects in other languages.
>
> Thanks,
> Mark
>
>
> On 4/15/21, 7:49 PM, "Udo Kohlmeyer"  wrote:
>
> @jake, you are correct, I did miss the LOCAL variable out of the
> 

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

[John Blum]

+1

Spring Data for Apache Geode 1.12.2 built successfully.

From: Dave Barnes 
Sent: Monday, April 19, 2021 9:19 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1
Built and reviewed User Guide and API docs. LGTM.

On Wed, Apr 14, 2021 at 3:43 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> 
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.2.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback (including the checks you
> performed).
>
> Voting deadline:
> 3PM PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667984361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ycIQ4dMv%2Baot0TXuDhBsrxB7CVjtkgjJWdq6u1Sq4CQ%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.2.RC1%2Fdata=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667984361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=q%2FhHp%2Bg08zKQFR%2BUzBka%2FBXszgcQHX7NoOcWysIenow%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6jvQf5ga8w%2FZsvspyHHsr%2Fsn4yetQ6aC0aLHM1ndJNw%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5oP%2BT3wXSOsH11BoOiTnZQ4KnxfTZ3OK35cvGXFWM%2FM%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lTBAnvGiEzRniIZtNSFFqju81AZRrYwodWjGrLgD8oM%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1NHd8IAOqmZcHgYS0BF6I4enwwxzrqRbYaB87%2Bt53NA%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4N0XwecPOvLnE9EucTUUbhIxFnXRhdqTnMAt77RwBDo%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=uEniMQ%2BY7CPB7kLfgouQvH8uYJf8EHu2VCXJkd7Zp2w%3Dreserved=0
>
> 

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[John Blum]

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-clientdata=04%7C01%7Cjblum%40vmware.com%7C194584c1dbf443f3dc2908d8f2e25613%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526401214937503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=IpWa%2B8ys08lGLfBmboJXiVOZN3ZWQH%2FP4VXNa3r1kcY%3Dreserved=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 n

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[John Blum]

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-clientdata=04%7C01%7Cjblum%40vmware.com%7C57064d5c95a942d5d45408d8ef9ef079%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522813216259200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B%2BH%2BrhN%2BfI1evkLtaONC%2FVliM7D7%2FUQbhLfFQ40yZBw%3Dreserved=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

On March 23, 2021 at 3:55:33 PM PDT, Udo Kohlmeyer  
wrote:
Alexander, as you know, the intent for this work was to lower the 
barrier of entry, as the Geode wire protocol is not documented, which makes it 
impossible to contribute any clients in other languages to the project. The 
lack of documentation of this feature did also not help the case.

If no-one else sees ANY benefit of having a self-describing wire 
protocol as part of the project, then you should remove it. But as stated, 
without AND documentation pertaining to the wire protocol for Geode, removing 
the only self-describing protocol with serialization, adopted by many globally, 
will put the barrier 

Re: Proposal: new Geode property CRITICAL_HEAP_PERCENTAGE

[John Blum]

Why is calling InternalResourceManager.setCriticalHeapPercentage(..) necessary?

This configuration setting is accessible from the public API 
GemFireCache.getResourceManager().setCriticalHeapPercentage(..).

Perhaps this configuration property can be specific to the Geode Redis module??

For instance, SDG also exposes certain properties to configure API only 
settings, e.g. [1], or alternatively, [2].


-j

[1] 
https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/config/annotation/ClientCacheApplication.html#criticalHeapPercentage--
[2] 
https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/config/annotation/PeerCacheApplication.html#criticalHeapPercentage--


From: Raymond Ingles 
Sent: Friday, February 26, 2021 11:05 AM
To: dev@geode.apache.org 
Subject: Proposal: new Geode property CRITICAL_HEAP_PERCENTAGE

The Geode Redis Compatibility code is working to emulate the Redis eviction 
policy “noevict”; when memory fills up, the server refuses new write commands 
until deletion or expiration has cleared space.

Right now, part of the implementation is calling 
InternalResourceManager.setCritialHeapPercentage() to ensure that 
LowMemoryExceptions are thrown before heap memory actually runs out. It makes 
sense to make this configurable rather than hardcoding the specific percentage, 
obviously.

Since this is a cache-wide setting (and probably useful to other components) we 
didn’t think it would necessarily be appropriate to add a redis-specific option 
(redis-critical-heap-percentage). What would the implications be to adding a 
general critical-heap-percentage parameter? Are there existing reasons that 
this hasn’t already been done? gfsh already supports these options when 
starting a member.

Does anyone have a strong preference (or aversion) to one or the other?

Re: [VOTE] Apache Geode 1.12.1.RC4

[John Blum]

To be clear SDG Neumann/2.3.x builds with Apache Geode 1.12.1, correctly.

+1

From: John Blum 
Sent: Wednesday, February 24, 2021 1:52 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.12.1.RC4

+1

Spring Data for Apache Geode builds with Apache Geode 1.12.1 RC bits.

From: Dave Barnes 
Sent: Wednesday, February 24, 2021 10:34 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.12.1.RC4

+1
Docs.
- Geode API docs header correctly updated to 1.12.1
- User guide build scripts generated correct 1.12.1 manual
- Native client user guides built correctly
- Native client api docs not tested -- they're generated by the full
software build, so I assume they're OK. We publish only the latest version
(1.13) on the Apache Geode website.

On Mon, Feb 22, 2021 at 10:23 AM Robert Houghton 
wrote:

> +1
>
> I verified the version.properties file contents to match the pipeline
> version that we've tested and verified.
> -Robert Houghton
>
>
> On 2/21/21, 12:08 PM, "Owen Nichols"  wrote:
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.1.RC4.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Thu, February 25 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.1.RC4
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.1data=04%7C01%7Cjblum%40vmware.com%7Cbf3cafb596db44c5a13d08d8d90e7c35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637498003524759118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=40DhiDcJdgeGBAVScqMP0XrQURzzIvpiLcqeqk%2BcXhM%3Dreserved=0
>
> Source and binary distributions:
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.1.RC4%2Fdata=04%7C01%7Cjblum%40vmware.com%7Cbf3cafb596db44c5a13d08d8d90e7c35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637498003524759118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=BZTsRh46XhIo7BRzQnpnCXWNHuwTeJCPd4cFYMXDtqM%3Dreserved=0
>
> Maven staging repo:
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1075data=04%7C01%7Cjblum%40vmware.com%7Cbf3cafb596db44c5a13d08d8d90e7c35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637498003524759118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5N5CfaZCBPo53YZ9Ps9dTvRVImDsja%2FqEBgg6%2F0QlZ8%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7Cbf3cafb596db44c5a13d08d8d90e7c35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637498003524759118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a3rufd2Mh8NOzZffTI4KhJflSCADbWVcZP0NslIEziI%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7Cbf3cafb596db44c5a13d08d8d90e7c35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637498003524759118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cHuDPu6l%2F3suzpxAQ2JYAc%2F14%2FrULQhQ%2B%2FzuP6MgoYs%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7Cbf3cafb596db44c5a13d08d8d90e7c35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637498003524759118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qdjjDp1ThFRZE8sToiUoDQgs97%2BDjl%2FHiadGPJjDYx8%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7Cbf3cafb596db44c5a13d08d8d90e7c35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637498003524769108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CbnQoWB9S2zvvwILVTrGwirvRehhv0o51DzBSyWPNg4%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-su

Re: [VOTE] Apache Geode 1.12.1.RC4

[John Blum]

+1

Spring Data for Apache Geode builds with Apache Geode 1.12.1 RC bits.

From: Dave Barnes 
Sent: Wednesday, February 24, 2021 10:34 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.12.1.RC4

+1
Docs.
- Geode API docs header correctly updated to 1.12.1
- User guide build scripts generated correct 1.12.1 manual
- Native client user guides built correctly
- Native client api docs not tested -- they're generated by the full
software build, so I assume they're OK. We publish only the latest version
(1.13) on the Apache Geode website.

On Mon, Feb 22, 2021 at 10:23 AM Robert Houghton 
wrote:

> +1
>
> I verified the version.properties file contents to match the pipeline
> version that we've tested and verified.
> -Robert Houghton
>
>
> On 2/21/21, 12:08 PM, "Owen Nichols"  wrote:
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.1.RC4.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Thu, February 25 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.1.RC4
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.1data=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852713256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qQDPqS2ypX%2BHNM1kpxMMF%2FOLdiqD4kPE38cPuO1cvrU%3Dreserved=0
>
> Source and binary distributions:
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.1.RC4%2Fdata=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852713256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=spJzwUcgvJiwRWJAv92JJdYFCAbq8RF5rmGYUyJTRfk%3Dreserved=0
>
> Maven staging repo:
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1075data=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852713256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lMggx8sBpF%2ByA4tIv%2FO40y2CDkO7qC9TxZ1WGojGYts%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852713256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fcXpAaYUe8WdDoLars0chHz49X5ikK47Hea6p%2ByApuc%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852723255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vzOmhDbRhwlwfow4nA5OKzIzUh4EF%2BsAxr8Q1jePQqU%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852723255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nB%2FTx8RKUqQndaUQLVc%2FqdAjnghd4SarB8yqjuDiA5c%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852723255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RoNqmvrdZqBazm4Q4%2F1nuQJ2%2BsfkeLwpXKy9zG0Y7Ho%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cjblum%40vmware.com%7C89212d5d329a4c69e24b08d8d8f2daa1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637497884852723255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NwmC4w5m3zr%2Fxohzx6r5blIRKs8bbGc7rXFGzfQg9ss%3Dreserved=0
>
> 

Re: [PROPOSAL] Change the default value of conserve-sockets to false

[John Blum]

I agree with Dan, here, along with the consensus that false is the better 
default (in most cases).

So, I simply want to re-iterate the importance of "documentation" in whatever 
direction we decide.  There are, without a doubt, both pros and cons to each 
configuration arrangement (true of false) where the conserve-sockets setting is 
concerned.  Let's just make sure our old and new users are aware, too.

-j

From: Dan Smith 
Sent: Wednesday, December 9, 2020 11:22 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

I will go ahead and withdraw my objection to this change. Based on some side 
conversations, at least at VMWare it sounds like we don't have customers that 
are not setting this flag. So the scenario I'm worried about where a customer 
upgrades their production cluster and has it crash due to this change seems 
less likely. I do agree false is a better default.

I would also be fine waiting until 2.0 to make this change.

-Dan

Re: Requests taking too long if one member of the cluster fails

[John Blum]

Hi Mario-


1) Regarding why only write to the primary (bucket) of a PR (?)... again, it 
has to do with consistency.

Fundamentally, a distributed system is constrained by CAP.  The system can 
either be consistent or available in the face of network partitions.  You 
cannot have your cake and eat it too, .

By design, Apache Geode favors consistency over availability.  However, it 
doesn't mean Geode becomes unavailable when a node or nodes, or the network, 
fails. With the ability to configure redundant copies, it is more like "limited 
availability" when a member or portion of the cluster is severed from the rest 
of the system, until the member(s) or network recovers.

But, to guarantee consistency, a single node (i.e. the "primary") hosting the 
PR must be "the source of truth".  If writes are allowed to go to secondaries, 
then you need a sophisticated consensus algorithm (e.g. Paxos, Raft) to resolve 
conflicts when 2 or more writes in different copies change the same logical 
object but differ in value.  Therefore, writes go to the primary and are then 
distributed to the secondaries (which require an ACK) while holding a lock.

If you think about this in object-oriented terms, the safest object in a highly 
concurrent system is an immutable one.  However, if an object can be modified 
by multiple Threads, then it is safer if all Threads access the object though 
the same control plane to uphold the invariants of the object.

NOTE: For an object, serializing access through synchronization does increase 
contention.  However, keep in mind that a PR does not just have 1 primary.  
Each bucket of the PR (defaults to 113; is tunable) has a primary thereby 
reducing contenting on writes.

Finally, Geode's consistency guarantees are much more sophisticated than what I 
described above. You can read more about Geode's consistency 
here<https://geode.apache.org/docs/guide/113/developing/distributed_regions/region_entry_versions.html>
 [1] (an entire chapter has been dedicated to this very important topic).



2) Regarding member-timeout...

Can this setting be too low?  Yes, of course; you must be careful.

Setting too low of a member-timeout could result in the system thrashing 
between the member being kicked out and the member rejoining the system.

This is costly because, after a member is kicked out, the system must "restore 
redundancy".  When the member rejoins, a "fence & merge" process occurs, then 
the system may need to "rebalance" the data.

Why would a node bounce between being a member, and part of the system, and 
getting kicked out?

Well, it depends on your infrastructure, for one.  If you have an unreliable 
network (more applicable in the cloud environments in certain cases), then 
minor but frequent network blips that severe 1 or more members could cause the 
member(s) to bounce between being kicked out and rejoining.  If enough members 
are severed from the system, then the system might need to decide on a quorum.

If a member is sick (e.g. running low on memory) thereby making the member 
seemingly unresponsive when in fact the member is just overloaded, this can 
cause issues.

There are many factors to consider when configuring Geode.  Don't simply set a 
property thinking it just solved my immediate problem when in fact it might 
have shifted the problem somewhere else.

The setting for member-timeout may very well be what you need, or you may need 
to consider other factors (e.g. the size of your system, both number of nodes 
as well as the size of the data, level of redundancy, you mention collocated 
data (this also is a factor), the environment, etc, etc).

This is the trickiest part of using any system like Geode.  You typically must 
tune it properly to your UC and requirements over several iterations to meet 
your SLAs.

This 
chapter<https://geode.apache.org/docs/guide/113/managing/monitor_tune/chapter_overview.html>
 [2] in the User Guide will be your friend.

I will let others chime in with their expertise/experience now.  Hopefully, 
this has given you some thoughts and things to consider.  Just remember, always 
test and measure, 

Cheers,
John


[1] 
https://geode.apache.org/docs/guide/113/developing/distributed_regions/region_entry_versions.html
[2] 
https://geode.apache.org/docs/guide/113/managing/monitor_tune/chapter_overview.html










From: Mario Salazar de Torres 
Sent: Saturday, November 21, 2020 1:40 PM
To: dev@geode.apache.org 
Cc: miguel.g.gar...@ericsson.com 
Subject: Re: Requests taking too long if one member of the cluster fails

Thanks @John Blum<mailto:jb...@vmware.com> for your detailed explanation! It 
helped me to better understand how redundancy works.

Thing is that all our use cases requires a really low response time when 
performing operations.
Under normal conditions a "put" takes a few milliseconds, but in the cas

Re: Requests taking too long if one member of the cluster fails

[John Blum]

DISCLAIMER: I am not knowledgeable about the Native Client (implementation) nor 
am I commenting specifically on the perf you are seeing, which can have many 
factors. However, in general...

Given you are performing "put" operations on a PR, then for consistency 
reasons, Geode is always going to "write" to the primary, on which ever member 
in the cluster hosts the primary for that particular PR (bucket).  So, if the 
member containing the primary for the PR goes down, then I would expect it to 
take more time than a normal "put" when no member goes down. Essentially, the 
cluster is going to shuffle things around and possible rebalance the cluster in 
order to restore redundancy. When rebalancing, having collocated Regions could 
even further impact timing.

When performing a "put" operation , having redundancy is not going to sustain 
or improve performance, if that was what you were expecting. In fact, it could 
even potentially negatively impact performance when a node goes down depending 
on the number of nodes and redundancy level.

Finally, if you were testing "gets" vs "puts", then I'd expect very little if 
any noticeable impact on performance, since you are using redundant copies, 
which should fail over in the case of a node failure.

Refer to the following sections in the User Guide for specfics:

1) Rebalancing PR Data: 
https://geode.apache.org/docs/guide/113/developing/partitioned_regions/rebalancing_pr_data.html
 (specifically, look at the section on 'How PR Rebalancing Works', which also 
talks about collocation).

2) Restoring Redundancy in PRs: 
https://geode.apache.org/docs/guide/113/developing/partitioned_regions/restoring_region_redundancy.html

3) Review your settings for 'member-timeout'. Search for this Geode property 
here:
https://geode.apache.org/docs/guide/113/reference/topics/gemfire_properties.html).


4) Also, be mindful of the PR's 'recovery delay':
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/PartitionAttributes.html#getRecoveryDelay--


There may be other server-side (cluster-wide) settings you can configure for 
node failures as well that I am not recalling off the top of my head.

Hope this helps,

-j


From: Mario Salazar de Torres 
Sent: Saturday, November 21, 2020 2:16 AM
To: dev@geode.apache.org 
Cc: miguel.g.gar...@ericsson.com 
Subject: Requests taking too long if one member of the cluster fails

Hi,

I've been looking into the following issue:
"Whenever performing a stress test on a Geode cluster and forcefully killing 
one of the members, all the threads in the application get stuck".

To give more context these are the conditions under the test is performed:

  *   A cluster is deployed with:
 *   2 locators.
 *   3 servers.
  *   2 partitioned regions are created and collocated with a third one (from 
now on called the "anchor").
 *   Also, regions have a single redundant copy configured.
 *   Whether or not to enable persistence on these regions do not affect to 
the test outcome.
 *   Note that we've configured a PartitionResolver for both of these 
regions.
  *   A geode-native test application is spin up with 20 threads sending a pack 
of 1 put request to each of the partitioned
regions regions (except for the "anchor"), all of that within a transaction. 
See example below to illustrate the kind of traffic sent:
void thread() {
  while(true) {
common_prefix = to_string(time(nullptr));
tx_manager->begin();
for(region_name : {"region_a", "region_b"}) {
  key = "key-" + common_prefix + "|" + to_string(rand());
  value = to_string(rand());
  cache->getRegion(region_name)->put(key, value);
}
tx_manager->commit();
  }
}

The test consists of:

  *   Spinning up the cluster.
  *   Running the application.
  *   One of the servers (from now on called "server-0") is forcefully 
restarted by
using kill -KILL  and after that starting it up again with gfsh.

The expectation of this test is that given that data has a redundant copy, and 
we have 2 servers up and running all the time, then writing data should be 
handled smoothly.
However, what actually happens is that all application threads end up being 
stuck.

So, in the process of troubleshooting, we noticed that there was several 
dead-locks in the geode-native client, which resulted in the following PRs:

  *   
https://github.com/apache/geode-native/pull/660
  *   

Re: [PROPOSAL] Change the default value of conserve-sockets to false

[John Blum]

The downside of conserve-sockets = false is that you are (essentially) back to 
a Thread|Socket / Request model (though Geode limits this system resource 
consumption to a degree by the use of Thread Pools in p2p distribution layer) 
and thus, you can run out of file descriptors (per newly opened Socket) pretty 
quickly if you are not careful.

conserve-sockets set to true limits the use of finite system resources why 
risking deadlocks (i.e. A -> B -> C -> A), which is also contingent on ACKS 
(and the infamous ReplyProcessor21; at least at 1 time, not sure if it is still 
in play, but probably!).

conserve-sockets set to false uses more system resources but avoids deadlocks.

If this change is made, I'd minimally make sure to document that users should 
adjust their (soft & hard) ulimits accordingly, based on use cases, load, etc.

Personally, this has caused enough grief in the past (both ways, actually!) 
that I 'd say this is a major version change.

-j



From: Nabarun Nag 
Sent: Wednesday, November 18, 2020 6:09 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

+1

  *   As nearly all of the production use-cases need "conserve-sockets" to be 
set to false, I think we can aim for changing the default value to false for 
1.14.0 release.
  *   We can highlight this change in the release notes and emails.

Regards,
Nabarun


From: Udo Kohlmeyer 
Sent: Wednesday, November 18, 2020 6:00 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

Hi there Donal,

Thank you for raising this. It is not an uncommon request to change the default 
value of this field.

This has been discussed many times in the past. I would LOVE to approve this 
change, but this would mean that users that don’t set this property might 
suddenly have this property changed. We are not sure that this would mean for 
these users. BUT

That said, there have been very little (to none) complaints about the product 
stability when `conserve-sockets=false` are set.

+1 - if we are allowed to make this change outside of a major version change.

--Udo

From: Donal Evans 
Date: Thursday, November 19, 2020 at 12:04 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Change the default value of conserve-sockets to false
Hi Geode dev,

First, from the docs[1], a brief explanation of the purpose of the 
conserve-sockets property:

"The conserve-sockets setting indicates whether application threads share 
sockets with other threads or use their own sockets for member communication. 
This setting has no effect on communication between a server and its clients, 
but it does control the server’s communication with its peers or a gateway 
sender’s communication with a gateway receiver."

The current default value for the conserve-sockets property is true, which at 
first glance makes sense, since in an ideal world, existing sockets could be 
shared between threads and there would be no need to create and destroy new 
sockets for each process, which can be somewhat resource-intensive. However, in 
practice, there are several known issues with using the default setting of 
true. From the docs[1]:

"For distributed regions, the put operation, and destroy and invalidate for 
regions and entries, can all be optimized with conserve-sockets set to false. 
For partitioned regions, setting conserve-sockets to false can improve general 
throughput.
Note: When you have transactions operating on EMPTY, NORMAL or PARTITION 
regions, make sure that conserve-sockets is set to false to avoid distributed 
deadlocks."

and[2]:

"WAN deployments increase the messaging demands on a Geode system. To avoid 
hangs related to WAN messaging, always set `conserve-sockets=false` for Geode 
members that participate in a WAN deployment."

Given that it is generally accepted as best practice to set conserve-sockets to 
false for almost all use cases of Geode beyond the most simple, it would make 
sense to also change the default value to false, to prevent people having to 
encounter a problem, search for the solution, then change the setting to what 
is almost always the "correct" value.

I have done some experimenting to see what it would take to make this proposal 
a reality, and the changes required are very minimal, with only two existing 
DUnit tests that need to be modified to explicitly set the value of 
conserve-sockets that were previously relying on the default being true.

Any feedback on this proposal would be very welcome, and if the response is 
positive, I can create a PR with the changes as soon as a decision is reached.

Thanks,
Donal

[1] 

Re: How to add a new REST end point in Cluster Management Service

[John Blum]

Hi Jinmei-

I put feedback and other comments in the Wiki page.

Regards,
John


From: Jinmei Liao 
Sent: Monday, October 26, 2020 10:53 AM
To: dev@geode.apache.org 
Subject: How to add a new REST end point in Cluster Management Service

Hi, Geode developers,

I just added a twiki page detailing how to add a new REST end point in Cluster 
Management Service to manage new entities or start new long running operations 
in Geode Cluster. Feel free to look it through and provide comments/suggestions.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2BA%2BREST%2BEnd%2Bpoint%2Bto%2BCluster%2BManagement%2BServicedata=04%7C01%7Cjblum%40vmware.com%7C302d5e04c4a740848b3c08d879d81af6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637393316392029047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KSiNyaHOptRWPRP5bbRiFbT50a5fDG%2FRd7IuoRZGiQQ%3Dreserved=0

Thanks!

Jinmei

Re: [DISCUSS] ServiceRegistry RFC

[John Blum]

FYI..

Spring's ApplicationContext is not necessarily Immutable (e.g. you can register 
a bean instances after the container has started, or mutate the Environment in 
some way as necessary by the application for lazy resources/initialization), 
but the bean configuration is "frozen" (effectively immutable) after the 
container starts.

From: Dan Smith 
Sent: Wednesday, October 21, 2020 2:58 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] ServiceRegistry RFC

You mentioned the metrics service - I think that is a good pattern to follow. 
For metrics the user passes configuration (The user's MeterRegistry) into the 
CacheFactory, and then the MetricsService hangs off the cache. Places in the 
code that need metrics fetch the MeterRegistry from the cache.

I don't really see this ServiceRegistryInstance as something that we would want 
to encourage any developers to use, since it is a singleton. I can see you 
might need a singleton for the ClassLoaderService because it's too hard to 
plumb your service into all the places you need it (I can understand that!) and 
ClassPathLoader is already a singleton. But we don't really want anything else 
to go in there, because of all the reasons we hate singletons.

For that reason, maybe it would be better just not to have this thing. Instead 
have a ClassPathServiceSingleton that is clearly a wart we should fix, or hang 
the ClassPathService off the cache, since we are already trying to find and 
eliminate places people are calling Cache.getInstance. That way you are not 
creating a tempting place for developers to stick more services where we really 
don't want them to.

-Dan

PS - I do like the idea of introducing a ServiceRegistry or something similar 
(Context, ?). It just should be scoped to a Cache or some shorter lifecycle. 
And it should be immutable (I believe spring's ApplicationContext might be?), 
so no adding and removing services from an instance of the ServiceRegistry or 
Context or whatever.

From: Udo Kohlmeyer 
Sent: Tuesday, October 20, 2020 3:01 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] ServiceRegistry RFC

Jens, that is a great thought. Lifecycle management would be amazing and I 
think we can definitely think about that. Right now, my thought of the services 
that are complimentary to the Cache. i.e the Cache uses them, but they 
themselves are not dependent on them.

I still see things like HttpService/GeodeRedisService/LuceneService to be 
modules that are dependent on the cache. Whereas the services that I’m looking 
at registering in the ServiceRegistry are services that will be used by the 
Cache and have no direct dependency on the Cache or it’s lifecycle.

e.g MetricsService can life outside of the cache, as there is no dependency on 
the cache to log a metric. The same would be true for the ClassLoaderService. 
As the reconnecting of the cache would not have an effect on the classes loaded.

But I like the idea of a lifecycle, but I think that discussion is better left 
for the broader discussion on lifecycle management of the Cache.

Hope this makes sense.

--Udo

From: Jens Deppe 
Date: Wednesday, October 21, 2020 at 8:46 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] ServiceRegistry RFC
One aspect this conversation has brought to mind is whether these services will 
require some kind of lifecycle management? If any of them require an instance 
of a Cache (and perhaps other components) they will need to be aware of the 
cache restarting (happens during reconnect).

Is that going to be a problem?

--Jens

On 10/20/20, 1:12 PM, "Udo Kohlmeyer"  wrote:

Hi there Dan,

We (Patrick and I) are in violent agreement about adding new singletons to 
the product. This singleton is merely there to avoid the complete utter 
re-write of the system to wire in said ServiceRegistry into the cache.

Yes, we are merely replacing 1 singleton with another, but we see it as a 
step in the right direction that we are replacing the usage with a generic 
service based implementation, that would allow for the simple “swap-in/out” of 
class loading (GEODE-8067).

Our inspiration for this ServiceRegistry is from Spring’s 
ApplicationContext, without all of the cool DI features that Spring would 
bring. We just needed a single location where one could add services and lookup 
them up.

We agree, singletons are bad. But hanging everything off InteralCache 
without a better designed lifecycle for module/component creation would make no 
sense. THAT is a design that we need to look at to better structure/separate 
modules/components.

Whilst doing GEODE-8466, and the replacing of ClassPathLoader with an 
instance-based ClassLoaderService, we found MANY static methods/functions that 
used the singleton ClassPathLoader, without ANY possibility to be able to wire 
in a ServiceRegistry instance. In addition, the current singleton is merely 
reducing the number of 

Re: [DISCUSS] ServiceRegistry RFC

[John Blum]

A word of caution here...

I'd like to see us start moving away from "internal" APIs even, as much as 
possible.  Moving away from Singletons is no-brainer, but less obvious, is 
moving things to proper public APIs and SPIs so that frameworks and tooling can 
extend Geode in interesting ways.  SDG certainly has a need in many cases.

By way of example, I am currently working on Pagination, and I keep running 
into situations where it would be nice if the same (ANTLR) grammar/parser used 
to parse OQL was an API SDG could use.

Essentially, every feature and function of Geode should have an interface 
(API/SPI) that can be extended (e.g. via plugins) in some way to effect 
function or behavior.  This is the primary driver behind the Open/Closed 
Principle, which would serve Geode well.

$0.02
-j



From: Dan Smith 
Sent: Tuesday, October 20, 2020 11:13 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] ServiceRegistry RFC

It might be better to hang things off InternalCache rather than create a new 
singleton. The cache is already a singleton, but we've been working on removing 
that by plumbing the cache everywhere. The cache is effectively our context 
object, and once we've finished removing calls to Cache.getInstance we will 
have a context object that is not a singleton.

As Jens mentioned, the cache already has the concept of CacheServices that can 
be retrieved using methods similar to what you listened in this RFC - eg 
InternalCache.getService(Class clazz).

Can we reuse/generalize/extend this existing service concept for your case?

-Dan

From: Jens Deppe 
Sent: Tuesday, October 20, 2020 5:33 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] ServiceRegistry RFC

Hi Udo,

Is the intention of this to replace (and extend) what we're doing with the 
traditional service loading mechanism today? i.e. how we're loading everything 
that extends CacheService (for example HttpService, LuceneService, 
GeodeRedisService, etc.).

Thanks
--jens



On 10/15/20, 7:25 PM, "Udo Kohlmeyer"  wrote:

Hi there Apache Geode Devs.

Please find attached an RFC for the introduction of a ServiceRegistry into 
Apache Geode.


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FServiceRegistrydata=04%7C01%7Cjblum%40vmware.com%7C3ee62dcb9d034f24526c08d87523f40c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637388144568538631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=eTRFhI0BECYgeUeimL1tKPI88vuI0SQ4LWWN4ZUWGb8%3Dreserved=0

Please add all comments to the RFC to this email for tracking and 
discussion.

--Udo

Re: [DISCUSS] One more 1.13 change

[John Blum]

+1


From: Dan Smith 
Sent: Monday, September 28, 2020 12:21 PM
To: dev@geode.apache.org 
Subject: [DISCUSS] One more 1.13 change

Hi,

I'd like to backport this change to support/1.13 as well

GEODE-8522: Switching exception log back to debug - 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5566data=02%7C01%7Cjblum%40vmware.com%7C6c125c591647400fdcd308d863e3b3bb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176913751568sdata=N7j85l7TN0l%2FarLxJkl1%2FtwBLSWrrMfTYVRzF8Xk12s%3Dreserved=0

This cleans up some noise in our logs that customers might see.
[https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Favatars3.githubusercontent.com%2Fu%2F47359%3Fs%3D400%26v%3D4data=02%7C01%7Cjblum%40vmware.com%7C6c125c591647400fdcd308d863e3b3bb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176913761570sdata=Q80xKsvdce1%2BIMXybp1%2BN2UnZjDkX77r9Kkrk3%2FK5os%3Dreserved=0]
GEODE-8522: Switching exception log back to debug (merge to 1.13) by 
upthewaterspout · Pull Request #5566 · 
apache/geode
This log message happens during the course of normal startup of multiple 
locators. We should not be logging a full stack trace during normal startup. 
(cherry picked from commit 3df057c) Thank you f...
github.com

Re: [VOTE] Apache Geode 1.13.0.RC1

[John Blum]

+1

Built Spring Data for Apache Geode (SDG) Ockham/2.4(2020-0-0) on Apache Geode 
1.13.0 (RC1), using the staging repository, successfully!

-John
SDG Lead



From: Apache 
Sent: Tuesday, September 8, 2020 4:07 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.13.0.RC1

+1 Looks good to me!

- Built from source and ran unit tests
- Used GFSH to create a locator and server and do some puts/gets
- Checked version in GFSH
- Built and ran all of the examples
- Verified SHAs and signatures

Aaron

> On Sep 8, 2020, at 3:33 PM, Jens Deppe  wrote:
>
> +1
>
> Actions performed:
>
> - Downloaded product .tgz bundle from maven co-ordinates
> - Verified GemFireVersion.properties matched SHA for 1.13.0 build tag
> - Started cluster with SSL enabled and ensured basic GFSH operations over 
> HTTPS
> - Connected GFSH v1.13.0 to newer cluster running v1.14.0
>
> --Jens
>
> On 9/7/20, 8:23 PM, "Dave Barnes"  wrote:
>
>Hello Geode Dev Community,
>
>
>This is a release candidate for Apache Geode version 1.13.0.RC1.
>
>Thanks to all the community members for their contributions to this 
> release!
>
>
>Please do a review and give your feedback, including the checks you
>performed.
>
>
>Voting deadline:
>
>3PM PDT Wed, September 9, 2020.
>
>
>Please note that we are voting upon the source tag:
>
>rel/v1.13.0.RC1
>
>
>Release notes:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.0data=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792901682sdata=XdocMiHrndGjaoifpyrSaXsLTbYyWMOw898ZBO39zzQ%3Dreserved=0
>
>
>Source and binary distributions:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.0.RC1%2Fdata=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792901682sdata=LbWEMCWk9hB2j6ftRt71tD7U0b0cofU1IA%2BJmW8VWTo%3Dreserved=0
>
>
>Maven staging repo:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1069data=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792911680sdata=zMyVf9yD81jCw7iYwdQ50MzNcgJxAQ3ytkQa7umsgTU%3Dreserved=0
>
>
>GitHub:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792911680sdata=yjeJsCp3ZpLxHkVVa90u4iMepahd8x0w%2FDBc9dH6uB4%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792911680sdata=YB4Ystk%2FFa0%2F8Ijapbm2Qxaqq4Zs0MtT61B2gS6UYNs%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792911680sdata=KrE%2FQrZTPuHAZF1vfrW4uN2rRpTz%2BOEpUG9X92lzx6I%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792911680sdata=%2FtxrwstDnvWUTGx1JzoDV%2FO46opi%2BKmnjIg9zkim9a8%3Dreserved=0
>
>
>Pipelines:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792911680sdata=zA1YufSkdGbFNHnN%2F43T9jjxHedXl6T6veZbTYcaRrM%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=02%7C01%7Cjblum%40vmware.com%7C663ad0764df6487c38a008d8544c0694%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352032792911680sdata=A7QtZhQ8i7BM0p0pV%2BuIZ8Ey8g%2FvjOtwAlubB80TVOk%3Dreserved=0
>
>
>Geode's KEYS file containing PGP keys we use to sign the release:
>
>
> 

Re: [Proposal] - RFC etiquette

[John Blum]

+1

From: Patrick Johnson 
Sent: Thursday, July 9, 2020 1:31 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] - RFC etiquette

+1

> On Jul 9, 2020, at 1:18 PM, Udo Kohlmeyer  wrote:
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we have 
> in place at the moment.
>
>  1.  All submitted RFC’s will provide a minimum 2 week review period. This is 
> to allow the community to review the RFC in a reasonable timeframe. If we 
> rush things, we will miss things. I’d rather have a little more time spent on 
> the RFC review and getting the approach “correct” than rushing the RFC and 
> then at a later point in time (either at PR review or worse production issue) 
> find out that the approach was less than optimal.
>  2.  Add a new section to the RFC. I would like to propose this section to be 
> labelled “Use Cases”. In this section I would like all submitters to describe 
> the use case that this RFC is to fulfill. This would include all possible 
> combinations (success and failure) and expected outcomes of each.
>
> I hope with the additions to the RFC process and template we can better round 
> out each RFC. Causing less delays later in the process and allowing all 
> community members to actively participate in the review process regardless of 
> technical skill level.
>
> Thoughts or comments?
>
> —Udo

Re: geode docker question

[John Blum]

Hi Barry-

Have a look at this...

https://docs.spring.io/spring-boot-data-geode-build/1.3.x/reference/html5/#geode-docker

I recently put this together as part of the SBDG 1.3 GA release.  It contains 
references to other pertinent documentation as well.

There aren't any pre-canned Docker Images with a Locator/Locators or 
Server/Servers running, unfortunately.

However, I intend to tackle that concern as part of the STDG project 
(https://github.com/spring-projects/spring-test-data-geode).  See Issue #19 
(https://github.com/spring-projects/spring-test-data-geode/issues/19) by myself 
and David Turanski.

Some early experimentation has already taken place.

Regards,
John




From: Barry Barrios 
Sent: Tuesday, July 7, 2020 10:26 AM
To: dev@geode.apache.org 
Subject: geode docker question

Do you have Apache Geode examples using docker? Is there a way to run a
docker container that automatically creates locator and server by
specifying some parameters without typing them in the gfsh shell prompt?
Also, same for deploying jars, is there a way to automatically deploy jars
when running docker? I was browsing through your apache geode examples
github repo to see if there were examples but didn't find what I was
looking for.

Best,
Barry

Re: Over usage of @SuppressWarnings

[John Blum]

Regarding...

*> public interface A is returning Region and not Region is that an
acceptable suppression?*

I think Geode API/Framework (e.g. PDX) (production) code should be very
explicit and *not* use *rawtypes*, or even *wildcard* types, for that
matter, as far as possible.

To be clear, I am saying sometimes in tests, *rawtypes* are useful.

Again, all of these things should be applied responsibly and judiciously,
with intent, especially in production code.

Use of *Java Generics* in code can cause as much grief for a user as it
does help in other cases (as Jake alluded to), so it needs to be careful
crafted, especially in public APIs as it affects more than test code, but
even application code that might require references to Geode objects.

-j


On Fri, May 8, 2020 at 1:30 PM Mark Hanson  wrote:

> It is slightly different, but here is a case I recently found.
>
> List versionTags = versions.getVersionTags();
>
> This method is internal though.
> public List getVersionTags() {
>   return Collections.unmodifiableList(this.versionTags);
> }
>
> Thanks,
> Mark
>
>
> > On May 8, 2020, at 1:25 PM, Mark Hanson  wrote:
> >
> > How does everyone feel about situations involving raw types?
> >
> > Such as public interface A is returning Region and not Region is
> that an acceptable suppression?
> >
> > Thanks,
> > Mark
> >
> >> On May 8, 2020, at 1:20 PM, John Blum  wrote:
> >>
> >> Agreed, but the following (inside tests) does not work in all cases,
> i.e.
> >>
> >> Region region...
> >>
> >> Particularly if "region" is passed to a method with a different type
> >> signature.
> >>
> >> I am trying to find/think of the situation I encounter from time to
> time,
> >> even when I use the *wildcard* signature (i.e. Region), but cannot
> >> currently find it (*#ugh*).
> >>
> >> Anyway, the point is, if the test is really not concerned with the type
> of
> >> values (*keys*, *values*) being stored in the mock *Region* then
> rawtypes (or
> >> sometimes Region) are useful in some cases since the point of the
> >> test is not about the data but perhaps about *Region* configuration in
> >> general, so adding types detracts (adds undue noise) to the code under
> test
> >> (IMO).
> >>
> >> It depends and is subjective.
> >>
> >> I agree, though, in general, @SuppressWarnings should be kept to a
> minimum
> >> and used only when necessary.
> >>
> >> -j
> >>
> >> On Fri, May 8, 2020 at 1:09 PM Kirk Lund  wrote:
> >>
> >>> Actually there is an alternative to using @SuppressWarnings for Mockito
> >>> mocks:
> >>>
> >>> Region region = cast(mock(Region.class));
> >>>
> >>> private static  T cast(Object object) {
> >>> return (T) object;
> >>> }
> >>>
> >>> Personally, I'd prefer to see warnings or workarounds like above than
> see
> >>> lots of @SuppressWarnings littered throughout our code base. I think
> it's a
> >>> smell of bad code.
> >>>
> >>> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett 
> wrote:
> >>>
> >>>>
> >>>>
> >>>>> On May 8, 2020, at 12:41 PM, Donal Evans  wrote:
> >>>>>
> >>>>> Is there a consensus on what constitutes a benign warning? I think
> the
> >>>> only
> >>>>> times I use @SuppressWarnings is in parameterized tests to suppress
> the
> >>>>> unused method warning for the parameters method, or for unchecked
> >>> casts,
> >>>> as
> >>>>> below:
> >>>>>
> >>>>> PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> >>>>> when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> >>>>>
> >>>>> where the thenReturn() would complain, since it's expecting to
> return a
> >>>>> Region.
> >>>>>
> >>>>> Would these be considered things that could safely just be ignored
> (and
> >>>> so
> >>>>> for which I can turn off inspection), or is the use of
> >>> @SuppressWarnings
> >>>>> here warranted?
> >>>>
> >>>> This is a legitimate suppression. There is no other way to correct the
> >>>> dysfunctional nature of Java Generics than to @SuppressWarnings. In
> this
> >>>> case though only that statement should be suppressed.
> >>>>
> >>>> -Jake
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> -John
> >> Spring Data Team
> >
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

Agreed, but the following (inside tests) does not work in all cases, i.e.

Region region...

Particularly if "region" is passed to a method with a different type
signature.

I am trying to find/think of the situation I encounter from time to time,
even when I use the *wildcard* signature (i.e. Region), but cannot
currently find it (*#ugh*).

Anyway, the point is, if the test is really not concerned with the type of
values (*keys*, *values*) being stored in the mock *Region* then rawtypes (or
sometimes Region) are useful in some cases since the point of the
test is not about the data but perhaps about *Region* configuration in
general, so adding types detracts (adds undue noise) to the code under test
(IMO).

It depends and is subjective.

I agree, though, in general, @SuppressWarnings should be kept to a minimum
and used only when necessary.

-j

On Fri, May 8, 2020 at 1:09 PM Kirk Lund  wrote:

> Actually there is an alternative to using @SuppressWarnings for Mockito
> mocks:
>
> Region region = cast(mock(Region.class));
>
> private static  T cast(Object object) {
>   return (T) object;
> }
>
> Personally, I'd prefer to see warnings or workarounds like above than see
> lots of @SuppressWarnings littered throughout our code base. I think it's a
> smell of bad code.
>
> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett  wrote:
>
> >
> >
> > > On May 8, 2020, at 12:41 PM, Donal Evans  wrote:
> > >
> > > Is there a consensus on what constitutes a benign warning? I think the
> > only
> > > times I use @SuppressWarnings is in parameterized tests to suppress the
> > > unused method warning for the parameters method, or for unchecked
> casts,
> > as
> > > below:
> > >
> > > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> > > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> > >
> > > where the thenReturn() would complain, since it's expecting to return a
> > > Region.
> > >
> > > Would these be considered things that could safely just be ignored (and
> > so
> > > for which I can turn off inspection), or is the use of
> @SuppressWarnings
> > > here warranted?
> >
> > This is a legitimate suppression. There is no other way to correct the
> > dysfunctional nature of Java Generics than to @SuppressWarnings. In this
> > case though only that statement should be suppressed.
> >
> > -Jake
> >
> >
>


-- 
-John
Spring Data Team

Re: Use of default methods in interfaces

[John Blum]

> *appropriate when the new method can be defined in terms of other
existing methods in the interface*

This is what it means when a method employs the "template" design pattern.

Correction to my (earlier) example:

@FunctionalInterace
interface Sorter {

default  Object[] sort(Object... array) {
return *sort*(Arrays.asList(array)).toArray();
}

> T *sort*(T collection);

}

-j

On Fri, May 8, 2020 at 1:03 PM Owen Nichols  wrote:

> Default interface methods are especially appropriate when the new method
> can be defined in terms of other existing methods in the interface.  For
> examples, when Collections added isEmpty(), it is basically just a
> shorthand for length()==0 [but certain subclasses might still be able to
> provide a more efficient implementation, for example a linked list might
> require traversing the entire list to get the length, while isEmpty could
> simply check the head].
>
> For public APIs, adding a new default interface method is safe (will not
> break source or binary compatibility), but for internal APIs, we don’t
> promise backward compatibility anyway.
>
> The pattern of adding a new default interface method with an empty
> implementation does concern me.  Perhaps a new interface that extends the
> original would be a more compile-time-verifiable way to express that new
> optional methods have been added that only some but not all implementations
> might implement?
>
>
> > On May 8, 2020, at 11:31 AM, John Blum  wrote:
> >
> > Another way to think about this is:
> >
> > 1. First, default methods are not inherently bad. They are useful in many
> > situations and can be "overridden" on implementing classes, if necessary.
> > 2. A default method should be provided when the operation is not strictly
> > required or if the implementation (procedure/algorithm) is rather simple
> > (e.g. following the template pattern), for example...
> >
> > @FunctionalInterace {
> > interface Sorter {
> >
> >default  Object[] sort(Object... array) {
> >return convert(Arrays.asList(array)).toArray();
> >}
> >
> >> T convert(T collection);
> >
> > }
> >
> > 3. If the interface footprint is small (as it should be) then it is
> > possible to use in *Lambda* expressions (and *Method References*), as
> > proper @FunctionalInterface as shown above, which is very useful when
> > composing *Streams*, etc.
> >
> > Food for thought.
> >
> > -j
> >
> >
> > On Fri, May 8, 2020 at 10:17 AM Jacob Barrett 
> wrote:
> >
> >> As a general rule default implementations on an interface should only
> used
> >> when absolutely necessary because all the implementations are out of
> your
> >> control. For example, the collection interfaces in the JDK all gained
> new
> >> APIs but Java doesn’t implement every instance of them so a default is
> >> necessary for forward progress. However, if you own all instances you
> >> should not need to use default. So in this particular PR the use of
> default
> >> in the InternalCache in my opinion is wrong. We should control all
> internal
> >> interfaces and therefor can update them all with the correct
> >> implementation.
> >>
> >> -Jake
> >>
> >>> On May 8, 2020, at 9:49 AM, Kirk Lund  wrote:
> >>>
> >>> I believe some of the Geode community has already decided that we
> >> shouldn't
> >>> overuse default methods in interfaces. Dan and others were the ones who
> >>> decided this and thus I can't really explain to folks in PRs why it's
> bad
> >>> to overuse default methods. Could some of the folks with strong
> >>> understanding of why we should avoid making every method default empty
> >>> please speak up here and/or in
> https://github.com/apache/geode/pull/5014
> >> ?
> >>>
> >>> My understanding is that default implementations should only be
> provided
> >> in
> >>> interfaces when it's important to do so for facilitating some sort of
> >>> deprecation and replacing a deprecated method.
> >>>
> >>> Thanks,
> >>> Kirk
> >>
> >>
> >
> > --
> > -John
> > Spring Data Team
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

I should clarify...

The use of ["rawtypes", "unchecked"] are quite common in test code and
"unused" is common in API/Framework (production) code

While *tests* make more liberal use of these checks  ("unused" is
questionable (!), though), I think all of these checks should be used
judiciously in production code.

-j


On Fri, May 8, 2020 at 12:50 PM John Blum  wrote:

> @Donal -
>
> Well, if you have code like...
>
> public void someMethod(@Nullable Object value) {
>
> Assert.notNull(value, "...");
>
> value.invokeSomeMethod();
>
> ...
> }
>
> The compiler will often *warn* you that value might be null without a
> proper null check.  That is, not all IDEs recognize "valid" null checks,
> particular if they are using some API/framework like AssertJ, perhaps.  For
> example:
>
> assertThat(value).isNotNull();
>
> NOTE: *AssertJ* use is valid and common outside of just tests!
>
> Usually the compiler only recognizes the assert keyword, i.e. ...
>
> assert value != null : "...";
>
> But the problem with Java assertions is you need to explicitly enable
> them, therefore most users use lib or framework/API (e.g. like *AssertJ*).
>
> I think other valid uses of the @SuppressWarnings annotation includes.
>
> *"rawtypes"*
> *"unchecked"* // particular around casting when the compiler is not smart
> enough to figure it out though you know it is safe; usually an instanceof
> check avoids these...
> *"unused"* // arguable, though
>
> Of course, use all of these judiciously and only when absolutely necessary
> or certain.
>
> I don't think it is OK to suppress deprecations (among other warnings)
> since those should be addressed!
>
> -j
>
>
> On Fri, May 8, 2020 at 12:44 PM Jacob Barrett  wrote:
>
>>
>>
>> > On May 8, 2020, at 12:41 PM, Donal Evans  wrote:
>> >
>> > Is there a consensus on what constitutes a benign warning? I think the
>> only
>> > times I use @SuppressWarnings is in parameterized tests to suppress the
>> > unused method warning for the parameters method, or for unchecked
>> casts, as
>> > below:
>> >
>> > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
>> > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
>> >
>> > where the thenReturn() would complain, since it's expecting to return a
>> > Region.
>> >
>> > Would these be considered things that could safely just be ignored (and
>> so
>> > for which I can turn off inspection), or is the use of @SuppressWarnings
>> > here warranted?
>>
>> This is a legitimate suppression. There is no other way to correct the
>> dysfunctional nature of Java Generics than to @SuppressWarnings. In this
>> case though only that statement should be suppressed.
>>
>> -Jake
>>
>>
>
> --
> -John
> Spring Data Team
>


-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

@Donal -

Well, if you have code like...

public void someMethod(@Nullable Object value) {

Assert.notNull(value, "...");

value.invokeSomeMethod();

...
}

The compiler will often *warn* you that value might be null without a
proper null check.  That is, not all IDEs recognize "valid" null checks,
particular if they are using some API/framework like AssertJ, perhaps.  For
example:

assertThat(value).isNotNull();

NOTE: *AssertJ* use is valid and common outside of just tests!

Usually the compiler only recognizes the assert keyword, i.e. ...

assert value != null : "...";

But the problem with Java assertions is you need to explicitly enable them,
therefore most users use lib or framework/API (e.g. like *AssertJ*).

I think other valid uses of the @SuppressWarnings annotation includes.

*"rawtypes"*
*"unchecked"* // particular around casting when the compiler is not smart
enough to figure it out though you know it is safe; usually an instanceof
check avoids these...
*"unused"* // arguable, though

Of course, use all of these judiciously and only when absolutely necessary
or certain.

I don't think it is OK to suppress deprecations (among other warnings)
since those should be addressed!

-j


On Fri, May 8, 2020 at 12:44 PM Jacob Barrett  wrote:

>
>
> > On May 8, 2020, at 12:41 PM, Donal Evans  wrote:
> >
> > Is there a consensus on what constitutes a benign warning? I think the
> only
> > times I use @SuppressWarnings is in parameterized tests to suppress the
> > unused method warning for the parameters method, or for unchecked casts,
> as
> > below:
> >
> > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> >
> > where the thenReturn() would complain, since it's expecting to return a
> > Region.
> >
> > Would these be considered things that could safely just be ignored (and
> so
> > for which I can turn off inspection), or is the use of @SuppressWarnings
> > here warranted?
>
> This is a legitimate suppression. There is no other way to correct the
> dysfunctional nature of Java Generics than to @SuppressWarnings. In this
> case though only that statement should be suppressed.
>
> -Jake
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

Let's try this again :P.

+1 to Kirk's comments.  Plus...

Another tip (for IJ IDEA users, probably same for Eclipse and other IDEs):

You can disable inspection for a warning that is otherwise benign (or not
correct) *rather than* unnecessarily annotating the code with
@SuppressWarnings.

However, disable inspections judiciously.  Warnings in code are telling you
something that needs to be paid attention to and disabling the warning with
(@SuppressWarnings) or disabling the inspection makes it easy to lose sight
that the warning is there when the code is revisited.

-j


On Fri, May 8, 2020 at 11:55 AM Jacob Barrett  wrote:

> I submitted and PR a while ago that started making warnings errors on
> certain modules. Through lazy consensus it was approved and merged. I would
> love to apply it to more. To set a baseline, I tried to fix most of the
> deprecated and other warnings as possible in the effected code. Many were
> so bad off that to just keep from getting worse I marked some suppressions.
> I tried to isolate to single statements, often by extracting the offending
> line out into its own method and annotating it.
>
> Prior to this almost ever bit of free space in the warning/error gutter in
> IntelliJ was take up by these warnings. The hope was by making them errors,
> fixing most and suppressing where necessary that it wouldn’t get any worse.
> It was hoped it would be signal to the next person in there deprecating
> something, using generics, or whatever, to do it right and clean up the
> effected code too. Just suppressing errors because you want to get it done
> is not a good practice. Effort should be taken and only as a last resort
> should something be suppressed That suppression should be limited to the
> smallest possible set of statements, which may mean extracting a bit fo
> code into a method.
>
> We most definitely should make it so we don’t add anymore suppressions but
> absolutely not at the expense of allowing warnings. The code should be
> fixed or refactored to remove the suppression.
>
> -Jake
>
>
> > On May 8, 2020, at 11:45 AM, Kirk Lund  wrote:
> >
> > I'm reviewing lots of PRs which are
> > adding @SuppressWarnings("deprecation"), etc. I think this is a bad
> trend.
> > We should not be suppressing warnings in our code. That's hiding a
> problem
> > that we'll need to or want to deal with in the future. Also, if you add
> > several of these suppress annotations into a class or a method or a test,
> > it really diminishes the readability. It adds noise and suppresses valid
> > warnings.
> >
> > On one of Jinmei's PRs, she responded saying she has to add these to her
> > code because of some change that Jake made to the build. Can we make it
> so
> > we don't have to add these suppressions?
> >
> > Thanks,
> > Kirk
>
>

-- 
-John
Spring Data Team

Re: Over usage of @SuppressWarnings

[John Blum]

Another tip (for IJ IDEA users, probably same for Eclipse and other IDEs):

You can disable an inspection wher

On Fri, May 8, 2020 at 11:52 AM Michael Oleske  wrote:

> For context, here is an example of PR that added warnings as error
> https://github.com/apache/geode/pull/4816.  Here is the JIRA
> https://issues.apache.org/jira/projects/GEODE/issues/GEODE-7869
>
> -michael
>
> On Fri, May 8, 2020 at 11:45 AM Kirk Lund  wrote:
>
> > I'm reviewing lots of PRs which are
> > adding @SuppressWarnings("deprecation"), etc. I think this is a bad
> trend.
> > We should not be suppressing warnings in our code. That's hiding a
> problem
> > that we'll need to or want to deal with in the future. Also, if you add
> > several of these suppress annotations into a class or a method or a test,
> > it really diminishes the readability. It adds noise and suppresses valid
> > warnings.
> >
> > On one of Jinmei's PRs, she responded saying she has to add these to her
> > code because of some change that Jake made to the build. Can we make it
> so
> > we don't have to add these suppressions?
> >
> > Thanks,
> > Kirk
> >
>


-- 
-John
Spring Data Team

Re: Use of default methods in interfaces

[John Blum]

Another way to think about this is:

1. First, default methods are not inherently bad. They are useful in many
situations and can be "overridden" on implementing classes, if necessary.
2. A default method should be provided when the operation is not strictly
required or if the implementation (procedure/algorithm) is rather simple
(e.g. following the template pattern), for example...

@FunctionalInterace {
interface Sorter {

default  Object[] sort(Object... array) {
return convert(Arrays.asList(array)).toArray();
}

> T convert(T collection);

}

3. If the interface footprint is small (as it should be) then it is
possible to use in *Lambda* expressions (and *Method References*), as
proper @FunctionalInterface as shown above, which is very useful when
composing *Streams*, etc.

Food for thought.

-j


On Fri, May 8, 2020 at 10:17 AM Jacob Barrett  wrote:

> As a general rule default implementations on an interface should only used
> when absolutely necessary because all the implementations are out of your
> control. For example, the collection interfaces in the JDK all gained new
> APIs but Java doesn’t implement every instance of them so a default is
> necessary for forward progress. However, if you own all instances you
> should not need to use default. So in this particular PR the use of default
> in the InternalCache in my opinion is wrong. We should control all internal
> interfaces and therefor can update them all with the correct
> implementation.
>
> -Jake
>
> > On May 8, 2020, at 9:49 AM, Kirk Lund  wrote:
> >
> > I believe some of the Geode community has already decided that we
> shouldn't
> > overuse default methods in interfaces. Dan and others were the ones who
> > decided this and thus I can't really explain to folks in PRs why it's bad
> > to overuse default methods. Could some of the folks with strong
> > understanding of why we should avoid making every method default empty
> > please speak up here and/or in https://github.com/apache/geode/pull/5014
> ?
> >
> > My understanding is that default implementations should only be provided
> in
> > interfaces when it's important to do so for facilitating some sort of
> > deprecation and replacing a deprecated method.
> >
> > Thanks,
> > Kirk
>
>

-- 
-John
Spring Data Team

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

[John Blum]

Among other problems I encountered, 1 problem that seemed to affect
*Integration
Tests* as I described was that the *Singleton* cache reference was not
cleaned up in a timely manner. Therefore, starting a fresh cache instance
(without coordination) in another *Integration Tests* would occasionally
throw a CacheExistsException (IIRC).

It would be roughly equivalent to ...

Cache cache = new CacheFactory().create();
// create more cache objects (Regions, Indexes, etc)
cache.close();
cache = new CacheFactory().create();  // EXCEPTION!!!

There is a lot of stuff (even asynchronous things) going on inside cache
close that can take time.  Even deallocation of system resources does not
always happen in a timely manner.

Kirk will undoubtedly remember other things he encountered as well.

-j


On Tue, Apr 14, 2020 at 3:45 PM Mark Hanson  wrote:

> I believe it is because of disk persistence among other things. Kirk would
> know for sure. He fixed the issue and his PR got shutdown.
> I totally support just fixing the bug.
>
> Let’s give Kirk a chance to chime in.
>
> Thanks,
> Mark
>
> > On Apr 14, 2020, at 3:39 PM, Dan Smith  wrote:
> >
> > IMO if it's not currently synchronous, that's just a bug that needs to be
> > fixed. If folks can provide details on what actually was asynchronous or
> > the particular test failures they saw, that would be helpful.
> >
> > Previously, when this came up it looks like Kirk found that close would
> not
> > wait for a different call to close() issued by a different thread [1]. Is
> > that still the bug we are running into? One that thread, it seems like we
> > also had a consensus we should just fix bugs with Cache.close:
> >
> > -Dan
> >
> > 1.
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Ff385a6dd51209e2706c68c9821412a6f22ebef3e809636060ac0bf55%40%253Cdev.geode.apache.org%253Edata=02%7C01%7Chansonm%40vmware.com%7C7a43463ab53c416234d908d7e0c4cc6b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637225008165230328sdata=GD77kAubDDWfP93zjYsNP61VMN4%2FKBAHcq95GwjeMBc%3Dreserved=0
> >
> > On Tue, Apr 14, 2020 at 3:23 PM John Blum  wrote:
> >
> >> My first thought is cache close (i.e. RegionService.close()  should be
> >> synchronous (by default), perhaps, with non-blocking options or options
> to
> >> wait for a set timeout as Jake suggested.
> >>
> >> This is a problem for *Integration Tests* (that start a peer cache
> >> instance, in-process or standalone) in general and not simply just
> >> "distributed" tests!  This is the reason I built support for this in
> >> *Spring
> >> Test for Apache Geode* (STDG) since subsequent tests requiring a peer
> cache
> >> instance (or CacheServer) may conflict with each other, especially
> given 1)
> >> the cache instance is a *Singleton* and 2) it is ideal to not have to
> >> restart the JVM between, even for *Integration Tests*, however, turns
> out
> >> to be a really common practice. *#ugh*  However, without proper
> >> coordination this can be a real problem, hence STDG's support.  Even
> when
> >> forking JVMs, you still have to be careful to wait in certain cases, as
> you
> >> could run into other conflicts (e.g. BindExceptions if not varying port
> >> numbers and such).  For all these reasons and more, it is important that
> >> the cache has fully shutdown and released all its resources.
> >>
> >> Also, while we are on this topic, I think it would be useful to have a
> >> dedicated interface for the cache instance lifecycle.  It's unfortunate
> the
> >> CacheListener interface is already taken for Region events. *#sigh*
> >>
> >> The interface might be something like...
> >>
> >> interface CacheLifecycleListener {
> >>
> >>  default void isStarting(CacheEvent event) {}
> >>
> >>  default void onStart(CacheEvent event) {}
> >>
> >>  default void isClosing(CacheEvent event) {}
> >>
> >>  default void onClose(CacheEvent event) {}
> >>
> >>  ...
> >>
> >> }
> >>
> >> -j
> >>
> >> On Tue, Apr 14, 2020 at 3:21 PM Jason Huynh  wrote:
> >>
> >>> The isClosed flag and method might be used currently more as an
> >> isClosing.
> >>> The GemFireCacheImpl.isClosed() method is actually returning isClosing.
> >>> Whatever change to isClosed that will be made, will have to properly
> >> handle
> >>> cases where it's meant to be treated as isClosing().
> >>>
&g

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

[John Blum]

My first thought is cache close (i.e. RegionService.close()  should be
synchronous (by default), perhaps, with non-blocking options or options to
wait for a set timeout as Jake suggested.

This is a problem for *Integration Tests* (that start a peer cache
instance, in-process or standalone) in general and not simply just
"distributed" tests!  This is the reason I built support for this in *Spring
Test for Apache Geode* (STDG) since subsequent tests requiring a peer cache
instance (or CacheServer) may conflict with each other, especially given 1)
the cache instance is a *Singleton* and 2) it is ideal to not have to
restart the JVM between, even for *Integration Tests*, however, turns out
to be a really common practice. *#ugh*  However, without proper
coordination this can be a real problem, hence STDG's support.  Even when
forking JVMs, you still have to be careful to wait in certain cases, as you
could run into other conflicts (e.g. BindExceptions if not varying port
numbers and such).  For all these reasons and more, it is important that
the cache has fully shutdown and released all its resources.

Also, while we are on this topic, I think it would be useful to have a
dedicated interface for the cache instance lifecycle.  It's unfortunate the
CacheListener interface is already taken for Region events. *#sigh*

The interface might be something like...

interface CacheLifecycleListener {

  default void isStarting(CacheEvent event) {}

  default void onStart(CacheEvent event) {}

  default void isClosing(CacheEvent event) {}

  default void onClose(CacheEvent event) {}

  ...

}

-j

On Tue, Apr 14, 2020 at 3:21 PM Jason Huynh  wrote:

> The isClosed flag and method might be used currently more as an isClosing.
> The GemFireCacheImpl.isClosed() method is actually returning isClosing.
> Whatever change to isClosed that will be made, will have to properly handle
> cases where it's meant to be treated as isClosing().
>
> On Tue, Apr 14, 2020 at 3:09 PM Mark Hanson  wrote:
>
> > Hi Jake,
> >
> > For Option 6: We could fix isClosed as well. That is a great suggestion.
> > Currently, it returns almost immediately.
> > I like your options though
> >
> > Any other thoughts?
> >
> > Any preferences? It think any of the current options seem better than the
> > current situation as long as we fix isClosed.
> >
> > Thanks,
> > Mark
> > 
> > From: Jacob Barrett 
> > Sent: Tuesday, April 14, 2020 2:30 PM
> > To: dev@geode.apache.org 
> > Subject: Re: [Discuss] Cache.close synchronous is not synchronous, but
> > code still expects it to be
> >
> > Option 4: Cache.closeAndWait(long timeout, TimeUnit unit) - Closes and
> > waits until it is really closed.
> > Option 5: Cache.close(Runnable closedCalleback) - Runs callback after
> > cache is really close.
> > Option 6: cache.close(); while (!cache.isClosed());
> >
> >
> > > On Apr 14, 2020, at 2:11 PM, Mark Hanson  wrote:
> > >
> > > Hi All,
> > >
> > > I know that we have discussed this once before, but I think it bears
> > repeating. We have test code that assumes cache.close is synchronous. It
> is
> > not. Not even close. I would like discuss some possible changes.
> > >
> > > Option 1. Call it what it is.  Deprecate Cache.close and create a new
> > method called asyncClose to replace it. Simple and descriptive.
> > > Option 2. Fix cache close so it is synchronous. Some might say that we
> > are going to break behavior, but I doubt any user relies on the fact that
> > it is asynchronous. That would be dangerous in and of itself. Obviously,
> we
> > don’t want to change behavior, but there have been a number of
> distributed
> > tests that have failed for this. If internal to the code devs don’t get
> it
> > right, where does that leave users.
> > > Option 3. Status quo.
> > >
> > > What do you think? Are there other options I am missing?
> > >
> > > Thanks,
> > > Mark
> > >
> >
> >
>


-- 
-John
Spring Data Team

Re: [VOTE] Apache Geode 1.12.0.RC4

[John Blum]

SDG continues to build with the Apache Geode 1.12.0 RC4 bits.

https://jenkins.spring.io/job/spring-data-geode/job/master-next/16/
https://github.com/spring-projects/spring-data-geode/commits/master-next

+1


On Fri, Mar 27, 2020 at 1:23 PM Anthony Baker  wrote:

> +1
>
> Things I checked:
> - expected files present
> - hashes and signatures present and valid
> - geode, geode-benchmarks, and geode-examples build from source
> - no binaries present in source distributions
> - verified that geode source and binary distributions have the correct
> SHA's
> - able to create a cluster and do region operations using gfsh
> - brief license review, no Cat X dependencies found
>
> Nitpicking:
>
> 1) Let's be consistent with names of source distribution and extensions.
> 2) NOTICE file copyright date needs to be updated for -native,
> -benchmark, -examples.
> 3) Some of the version numbers in LICENSE need to updated to match,
> also need to add asm-5.0.4.jar
>
> Anthony
>
> On Fri, Mar 27, 2020 at 11:37 AM Ernest Burghardt 
> wrote:
> >
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.12.0.RC4.
> > Thanks to all the community members for their contributions to this
> release!
> >
> > Please do a review and give your feedback, including the checks you
> > performed.
> >
> > Voting deadline:
> > 3PM PST Mon, March 30, 2020.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.12.0.RC4
> >
> > Release notes:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.0
> >
> > Source and binary distributions:
> > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1068
> >
> > GitHub:
> > https://github.com/apache/geode/tree/rel/v1.12.0.RC4
> > https://github.com/apache/geode-examples/tree/rel/v1.12.0.RC4
> > https://github.com/apache/geode-native/tree/rel/v1.12.0.RC4
> > https://github.com/apache/geode-benchmarks/tree/rel/v1.12.0.RC4
> >
> > Pipelines:
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-main
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-rc
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Command to run geode-examples:
> > ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4
> > -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1068
> > build runAll
> >
> > Regards
> > Ernie Burghardt
>


-- 
-John
Spring Data Team

Re: [VOTE] Apache Geode 1.12.0.RC1

[John Blum]

SDG builds successfully with the Apache Geode 1.12.0 RC bits.

It is a +1 from me when the rest of the problems are addressed.

SDG build for Apache Geode (next), is here [1].

[1] https://jenkins.spring.io/job/spring-data-geode/job/master-next/


On Thu, Mar 26, 2020 at 10:28 AM Anthony Baker  wrote:

> >
> > iii) As long as we need to make an RC2 anyway, I personally feel that it
> would be nice to align geode-native to its recent milestone
> (build/v10.1.0-build.254 / commit hash 35fcb1a66).  The current release
> branch is about half-a-dozen fixes behind this milestone.
>
> I’m not seeing the milestone you mentioned above.  Anyway, is there a
> critical need to pull in these changes?  Given that we’re (hopefully) on
> the eve of getting this release shipped I’m not sure we should reset the
> release branch.
>
> Anthony
>
>

-- 
-John
Spring Data Team

Re: [PROPOSAL] Include fix for GEODE-7763 into release 1.12.0

[John Blum]

+1

On Wed, Mar 18, 2020 at 11:52 AM Owen Nichols  wrote:

> +1
>
> > On Mar 18, 2020, at 11:49 AM, Dick Cavender 
> wrote:
> >
> > +1
> >
> > On Wed, Mar 18, 2020 at 11:43 AM Nabarun Nag  wrote:
> >
> >> +1
> >>
> >> On Wed, Mar 18, 2020 at 11:41 AM Jason Huynh  wrote:
> >>
> >>> Hello Dev list,
> >>>
> >>> I'd like to include a fix for GEODE-7763 in release 1.12.0.
> >>> The change removes the call to exportValue, preventing a serialization,
> >>> when no clients are waiting for the specific event.
> >>> The reason why I think it should be in the release is that we noticed a
> >>> negative effect on performance for a specific use case, in 1.12 from a
> >>> change that made us more "consistent" in that use case.  This change
> >>> doesn't modify the fix much, but does bring performance back inline (if
> >> not
> >>> better) than before.
> >>>
> >>> The sha is b4c3e9413f0008635b0a0c9116c96147d1e4ceec
> >>>
> >>> Thanks,
> >>> -Jason
> >>>
> >>
>
>

-- 
-John
Spring Data Team

Re: Discussion on Deprecation

[John Blum]

Additionally, it'd be ideal if the deprecated method were then adapted to
delegate to the new approach.  This will cut down on the number of required
tests since then you only need a Unit Tests asserting the method performs
the translation/delegating appropriately, unless of course the behavior is
changing too.

On Tue, Mar 17, 2020 at 8:57 AM Udo Kohlmeyer  wrote:

> I think we are also missing the other side of the coin.
>
> Once we deprecate something and we now need a equivalent test that tests
> the same behavior using the new method/approach. i.e now we have to
> double up on the testing of said deprecated method/feature/class. First
> we have to keep the tests around that use the deprecated and now we need
> the same test for the new. Otherwise we cannot ever be certain that both
> approaches work.
>
> In addition to this, if we don't create both tests, we have to create
> all the tests at the time of removal, otherwise we lose coverage.
>
> --Udo
>
> On 3/16/20 9:27 AM, Joris Melchior wrote:
> > +1 on leaving testing of deprecated functionality in place
> >
> > On Mon, Mar 16, 2020 at 11:50 AM Dan Smith  wrote:
> >
> >> +1
> >>
> >> One point though - we do need to leave some tests that specifically test
> >> the deprecated method(s), since we still support the deprecated APIs
> until
> >> we remove them. Everything else should be converted.
> >>
> >> -Dan
> >>
> >> On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett 
> wrote:
> >>
> >>> Hey Team,
> >>>
> >>> When deprecating a symbol, like class or method, please included a
> >>> reference to the replacement in the java docs. Also please include an
> >>> example of converting from the old API to the new. I am finding many
> many
> >>> places in the source where deprecated code has no hints at all. As many
> >> of
> >>> us don’t take the effort to immediately convert old tests over to the
> new
> >>> APIs the context is lost when someone finally does get around to it.
> For
> >>> public APIs this is extremely important so that users know how to
> migrate
> >>> their code with as few roadblocks as possible.
> >>>
> >>> Here is an example of something that is much better than most of what I
> >> am
> >>> seeing.
> >>>
> >>> /**
> >>>   * @deprecated Replaced with something better and safer.
> >>>   * Replaced by {@link Bar}.
> >>>   */
> >>> @Deprecated
> >>> class Foo {
> >>>/**
> >>> * Do something.
> >>> *
> >>> * @deprecated Replaced with something better.
> >>> * Replaced by {@link Bar#doSomethingBetter()}
> >>> */
> >>>@Deprecated
> >>>public void doSomething() {}
> >>>
> >>>/**
> >>> * Do something.
> >>> *
> >>> * @deprecated Implementation is not safe.
> >>> * Replaced with {@link Bar#doSomethingBetter()} and {@link
> >>> Bar#doSomethingElse()}.
> >>> * Migration example, replace:
> >>> * {@code
> >>> *   Foo foo = new Foo();
> >>> *   foo.doSomethingAndSomethingElse();
> >>> * }
> >>> * with:
> >>> * {@code
> >>> *   Bar bar = Bar();
> >>> *   bar.doSomethingBetter();
> >>> *   bar.doSomethingElse();
> >>> * }
> >>> */
> >>>@Deprecated
> >>>public void doSomethingAndSomethingElse() {}
> >>> }
> >>>
> >>> class Bar {
> >>>public void doSomethingBetter() {}
> >>>public void doSomethingElse() {}
> >>> }
> >>>
> >>> -Jake
> >>>
> >>>
> >
>


-- 
-John
Spring Data Team

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Again, we should keep the API footprint *small* and quit adding overrides
for every type of Proxy we would (potentially) support.  What is the point
of an abstraction/type-hierarchy if you don't use it?

The Enum would give users the possible range of currently supported Proxies
anyway.

Additionally, if you wanted something more specific, then you could
introduce a generic type signature, which is more useful for return types,
but work equally well for parameters as well...

interface PoolFactory {

  void setProxy(P config);

}

Of course, this assumes you would have multiple different types of
PoolFactory, which Geode does not currently, but could.

Generic parameters are more useful for return types, and the entire
PoolFactory, and don't necessarily need a generic type signature on the
enclosing type, for example:

interface PoolFactory {

 P getProxy();

}

-j


On Tue, Mar 10, 2020 at 10:38 AM Udo Kohlmeyer  wrote:

> I disagree.
>
> I think /setProxy(ProxyConfiguration)/ is 1st prize.
>
> If we are concerned that users will not know WHAT options are
> available.. We could always have a static builder for our supported
> options.
>
> --Udo
>
> On 3/10/20 10:07 AM, Dan Smith wrote:
> > Ok, how about this?
> >
> > setProxy(SniProxyConfiguration config)
> >
> > interface SniProxyConfiguration extends ProxyConfiguration {
> > static SniProxyConfiguration create(String host, int port);
> > String getHost();
> > int getPort()
> > }
> >
> > The main difference here from John's proposal being that setProxy takes a
> > SniProxyConfiguration, rather than the base ProxyConfiguration. We can
> > overload setProxy later if needed.
> >
> > The reason I'm not as keen on setProxy(ProxyConfiguration) is that it is
> > hard for the user to discover the different types of ProxyConfiguration
> > subclasses and know what is supported.
> >
> > -Dan
> >
> > On Mon, Mar 9, 2020 at 11:23 PM John Blum  wrote:
> >
> >> Corrections ( :-P ), my apologies...
> >>
> >> Iterable proxyConfigurations = ...;
> >>
> >> StreamSupport.stream(proxyConfiguration*s*.*spliterator*(), false)
> >>  .filter(config -> config.getType.isSecure()) *// This could be
> >> improved; see below...*
> >>  .*forEach*(config -> // do something with *each* secure proxy
> >> *config*).
> >>
> >> Although, I am sure you got the point, ;-)
> >>
> >> With improvement:
> >>
> >> interface ProxyConfiguration {
> >>
> >>ProxyType getType();
> >>
> >>// null-safe!
> >>default boolean isSecure() {
> >>  ProxyType type = getType();
> >>  return type != null && type.isSecure();
> >>}
> >> }
> >>
> >> Then:
> >>
> >> StreamSupport.stream(..)
> >> *.filter(ProxyConfiguration::isSecure)*
> >>  .forEach(...);
> >>
> >>
> >> Again, completely contrived.
> >>
> >> Cheers!
> >> -j
> >>
> >>
> >>
> >> On Mon, Mar 9, 2020 at 11:14 PM John Blum  wrote:
> >>
> >>> Yes, it's redundant (i.e. Enum + class type).
> >>>
> >>> However, having an Enum in addition to a specific type (1 reason I
> >>> defaulted the getType() method) can still be useful, such as in a
> switch
> >>> statement for example.  Enums are, well, easier to enumerate (useful in
> >>> Streams with filters).  Maybe you are going to classify certain Proxy's
> >>> by Enum type, for example:
> >>>
> >>> enum ProxyType {
> >>>
> >>>  ONE,
> >>>  TWO,
> >>>  THREE;
> >>>
> >>>  // Contrived example
> >>>  public boolean isSecure() {
> >>>  return Arrays.asList(ONE, THREE).contains(this);
> >>>  }
> >>> }
> >>>
> >>> Then:
> >>>
> >>> Iterable proxyConfigurations = ...;
> >>>
> >>> StreamSupport.stream(proxyConfiguration.spilterator(), false)
> >>>  .filter(config -> config.getType.isSecure())
> >>>  .ifPresent(config -> // do something with secure proxy).
> >>>
> >>>
> >>> Food for thought.
> >>>
> >>> -j
> >>>
> >>>
> >>>
> >>> On Mon, Mar 9, 2020 at 7:11 PM Jacob Barrett 
> >> wrote:
> >>>> Yes it’s redundant.
> >>>&g

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Corrections ( :-P ), my apologies...

Iterable proxyConfigurations = ...;

StreamSupport.stream(proxyConfiguration*s*.*spliterator*(), false)
.filter(config -> config.getType.isSecure()) *// This could be
improved; see below...*
.*forEach*(config -> // do something with *each* secure proxy *config*).

Although, I am sure you got the point, ;-)

With improvement:

interface ProxyConfiguration {

  ProxyType getType();

  // null-safe!
  default boolean isSecure() {
ProxyType type = getType();
return type != null && type.isSecure();
  }
}

Then:

StreamSupport.stream(..)
*.filter(ProxyConfiguration::isSecure)*
.forEach(...);


Again, completely contrived.

Cheers!
-j



On Mon, Mar 9, 2020 at 11:14 PM John Blum  wrote:

> Yes, it's redundant (i.e. Enum + class type).
>
> However, having an Enum in addition to a specific type (1 reason I
> defaulted the getType() method) can still be useful, such as in a switch
> statement for example.  Enums are, well, easier to enumerate (useful in
> Streams with filters).  Maybe you are going to classify certain Proxy's
> by Enum type, for example:
>
> enum ProxyType {
>
> ONE,
> TWO,
> THREE;
>
> // Contrived example
> public boolean isSecure() {
> return Arrays.asList(ONE, THREE).contains(this);
> }
> }
>
> Then:
>
> Iterable proxyConfigurations = ...;
>
> StreamSupport.stream(proxyConfiguration.spilterator(), false)
> .filter(config -> config.getType.isSecure())
> .ifPresent(config -> // do something with secure proxy).
>
>
> Food for thought.
>
> -j
>
>
>
> On Mon, Mar 9, 2020 at 7:11 PM Jacob Barrett  wrote:
>
>> Yes it’s redundant.
>>
>> > On Mar 9, 2020, at 5:08 PM, Bill Burcham 
>> wrote:
>> >
>> > What I like about John's full-fledged-class-per-proxy-kind is that
>> > everything that can potentially vary with proxy kind is all together in
>> a
>> > single object.
>> >
>> > That being said, John, in your SniProxyConfiguration, it seems to me
>> that
>> > the class itself (SniProxyConfiguration) could easily stand for the
>> proxy
>> > "type". If that's true then we could view ProxyType as redundant and
>> simply
>> > eliminate it right?
>> >
>> >> On Mon, Mar 9, 2020 at 2:41 PM Jacob Barrett 
>> wrote:
>> >>
>> >> +1 to Anthony and John. See similar comments in the RFC.
>> >>
>> >>>> On Mar 9, 2020, at 12:08 PM, Anthony Baker 
>> wrote:
>> >>>
>> >>> I’m not suggesting encoding the the proxy type in the URI.  Just
>> >> wondering if we can support stronger typing than String for defining
>> >> host/port/url configuration.  As John notes, later in the thread,
>> perhaps
>> >> using a configuration interface may help.
>> >>>
>> >>> Anthony
>> >>>
>> >>>
>> >>>> On Mar 9, 2020, at 11:11 AM, Bill Burcham 
>> >> wrote:
>> >>>>
>> >>>> Anthony and Jacob, I can see how the proposed ProxyType parameter
>> could
>> >> fit
>> >>>> into the scheme part of a a URI. However, the problem that
>> introduces is
>> >>>> that we would then have to pick (named) URL schemes to support. But
>> URL
>> >>>> schemes are standardized and it's not obvious which of the standard
>> ones
>> >>>> might apply here.
>> >>>>
>> >>>> If we couldn't adopt a standard scheme, we'd have to make one up. At
>> >> that
>> >>>> point I question the value of putting the (made-up) scheme into a URI
>> >>>> string.
>> >>>>
>> >>>> For this reason, I am a fan of the ProxyType parameter over a made-up
>> >> URL
>> >>>> scheme.
>> >>>>
>> >>>> That leaves open Anthony's other idea: eliminating the ProxyType
>> >> parameter
>> >>>> in favor of a separate method to set each kind of proxy. In the
>> current
>> >>>> RFC, that's just one, e.g. setPoolProxyWithSNI. I guess that comes
>> down
>> >> to:
>> >>>> what's the likelihood of us supporting other proxy types soon, and
>> then
>> >>>> what's the value of having a single method (and multiple enums)
>> versus
>> >>>> multiple methods (and no enum). If we thought the proxyAddress
>> parameter
>> >>>> wou

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Yes, it's redundant (i.e. Enum + class type).

However, having an Enum in addition to a specific type (1 reason I
defaulted the getType() method) can still be useful, such as in a switch
statement for example.  Enums are, well, easier to enumerate (useful in
Streams with filters).  Maybe you are going to classify certain Proxy's by
Enum type, for example:

enum ProxyType {

ONE,
TWO,
THREE;

// Contrived example
public boolean isSecure() {
return Arrays.asList(ONE, THREE).contains(this);
}
}

Then:

Iterable proxyConfigurations = ...;

StreamSupport.stream(proxyConfiguration.spilterator(), false)
.filter(config -> config.getType.isSecure())
.ifPresent(config -> // do something with secure proxy).


Food for thought.

-j



On Mon, Mar 9, 2020 at 7:11 PM Jacob Barrett  wrote:

> Yes it’s redundant.
>
> > On Mar 9, 2020, at 5:08 PM, Bill Burcham  wrote:
> >
> > What I like about John's full-fledged-class-per-proxy-kind is that
> > everything that can potentially vary with proxy kind is all together in a
> > single object.
> >
> > That being said, John, in your SniProxyConfiguration, it seems to me that
> > the class itself (SniProxyConfiguration) could easily stand for the proxy
> > "type". If that's true then we could view ProxyType as redundant and
> simply
> > eliminate it right?
> >
> >> On Mon, Mar 9, 2020 at 2:41 PM Jacob Barrett 
> wrote:
> >>
> >> +1 to Anthony and John. See similar comments in the RFC.
> >>
>  On Mar 9, 2020, at 12:08 PM, Anthony Baker  wrote:
> >>>
> >>> I’m not suggesting encoding the the proxy type in the URI.  Just
> >> wondering if we can support stronger typing than String for defining
> >> host/port/url configuration.  As John notes, later in the thread,
> perhaps
> >> using a configuration interface may help.
> >>>
> >>> Anthony
> >>>
> >>>
>  On Mar 9, 2020, at 11:11 AM, Bill Burcham 
> >> wrote:
> 
>  Anthony and Jacob, I can see how the proposed ProxyType parameter
> could
> >> fit
>  into the scheme part of a a URI. However, the problem that introduces
> is
>  that we would then have to pick (named) URL schemes to support. But
> URL
>  schemes are standardized and it's not obvious which of the standard
> ones
>  might apply here.
> 
>  If we couldn't adopt a standard scheme, we'd have to make one up. At
> >> that
>  point I question the value of putting the (made-up) scheme into a URI
>  string.
> 
>  For this reason, I am a fan of the ProxyType parameter over a made-up
> >> URL
>  scheme.
> 
>  That leaves open Anthony's other idea: eliminating the ProxyType
> >> parameter
>  in favor of a separate method to set each kind of proxy. In the
> current
>  RFC, that's just one, e.g. setPoolProxyWithSNI. I guess that comes
> down
> >> to:
>  what's the likelihood of us supporting other proxy types soon, and
> then
>  what's the value of having a single method (and multiple enums) versus
>  multiple methods (and no enum). If we thought the proxyAddress
> parameter
>  would carry different information across proxy types that might tilt
> us
>  toward the separate methods. The two on the table, however, (SNI,
> >> SOCKS5)
>  both have identical proxyAddress information.
> 
>  On Mon, Mar 9, 2020 at 10:54 AM Bill Burcham 
> >> wrote:
> 
> > By popular demand we are extending the RFC review period. I know Udo
> >> asked
> > for Friday (and Joris +1'd it), but since this is a small RFC, we'd
> >> like to
> > try to close it by Wednesday, March 11, ok?
> >
> > On Mon, Mar 9, 2020 at 10:39 AM Jacob Barrett 
> >> wrote:
> >
> >> I raised similar concerns as a comment in the RFC.
> >>
> >>> On Mar 9, 2020, at 10:29 AM, Anthony Baker 
> >> wrote:
> >>>
> >>> Given this new API:
> >>>
> >>> setPoolProxy(ProxyType type, String proxyAddress)
> >>>
> >>> The ProxyType enum seems to be a look ahead at supporting other
> kinds
> >> of proxies.  What is your thinking about using the enum vs specific
> >> named
> >> API’s (e.g. setPoolProxyWithSNI).
> >>>
> >>> Currently the definition of the proxyAddress seems to be dependent
> of
> >> the proxy type.  Did you consider stronger typing using an URI
> >> parameter
> >> type?
> >>>
> >>> Anthony
> >>>
> >>>
> >>>
>  On Mar 6, 2020, at 11:04 AM, Bill Burcham  >
> >> wrote:
> 
>  Please review the RFC for *Client side configuration for a SNI
> >> proxy*:
> 
> 
> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> 
>  Please comment by Monday, March 9, 2020.
> 
>  Regards,
>  Bill and Ernie
> >>>
> >>
> >
> >>>
> >>
> >>
>


-- 
-John
Spring Data Team

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

Actually, a modification and note...

NOTE: Obviously, host/port might apply to more than 1 ProxyType or all.
This is just example.

And, I would define SniProxyConfiguration as...

interface SniProxyConfiguration {

  default ProxyType getType() {
return ProxyType.SNI;
  }

  String getHost();

  int getPort();

}

-j

On Mon, Mar 9, 2020 at 11:29 AM John Blum  wrote:

> +1 to using an Enum over separate methods.  Less is more and having a
> smaller footprint (API) is better than an overloaded one where the number
> of methods could easily explode.  That is smart design.
>
> Additionally, it is not hard to introduce a bit more abstraction if the
> parameters might vary by ProxyType.
>
> For example:
>
> setProxy(ProxyConfiguration config)
>
> Where ProxyConfiguration is defined as...
>
> interface ProxyConfiguration {
>
>   ProxyType getType();
>
> }
>
> Then:
>
> interface SniProxyConfiguration extends ProxyConfiguration {
>
>   String getHost();
>
>   int getPort();
>
> }
>
> Food for thought,
>
> -j
>
>
> On Mon, Mar 9, 2020 at 11:21 AM Dan Smith  wrote:
>
>> > What is your thinking about using the enum vs specific named API’s (e.g.
>> setPoolProxyWithSNI).
>>
>> I think the nice thing about the enum is over separate methods is that
>> it's
>> strongly typed, but it might still allow us to support additional proxy
>> types in the future with less modifications for code that wraps the API
>> (eg, cache.xml), or Spring Data Geode. It also makes it clear you can only
>> set one type of proxy.
>>
>> +1 to what Bill said. I could be convinced to use setProxy(ProxyType,
>> String host, int port) however.
>>
>> -Dan
>>
>>
>> On Mon, Mar 9, 2020 at 10:54 AM Bill Burcham 
>> wrote:
>>
>> > By popular demand we are extending the RFC review period. I know Udo
>> asked
>> > for Friday (and Joris +1'd it), but since this is a small RFC, we'd
>> like to
>> > try to close it by Wednesday, March 11, ok?
>> >
>> > On Mon, Mar 9, 2020 at 10:39 AM Jacob Barrett 
>> wrote:
>> >
>> > > I raised similar concerns as a comment in the RFC.
>> > >
>> > > > On Mar 9, 2020, at 10:29 AM, Anthony Baker 
>> wrote:
>> > > >
>> > > > Given this new API:
>> > > >
>> > > >setPoolProxy(ProxyType type, String proxyAddress)
>> > > >
>> > > > The ProxyType enum seems to be a look ahead at supporting other
>> kinds
>> > of
>> > > proxies.  What is your thinking about using the enum vs specific named
>> > > API’s (e.g. setPoolProxyWithSNI).
>> > > >
>> > > > Currently the definition of the proxyAddress seems to be dependent
>> of
>> > > the proxy type.  Did you consider stronger typing using an URI
>> parameter
>> > > type?
>> > > >
>> > > > Anthony
>> > > >
>> > > >
>> > > >
>> > > >> On Mar 6, 2020, at 11:04 AM, Bill Burcham 
>> > > wrote:
>> > > >>
>> > > >> Please review the RFC for *Client side configuration for a SNI
>> proxy*:
>> > > >>
>> > > >>
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
>> > > >>
>> > > >> Please comment by Monday, March 9, 2020.
>> > > >>
>> > > >> Regards,
>> > > >> Bill and Ernie
>> > > >
>> > >
>> >
>>
>
>
> --
> -John
> Spring Data Team
>


-- 
-John
Spring Data Team

Re: RFC - Client side configuration for a SNI proxy

[John Blum]

+1 to using an Enum over separate methods.  Less is more and having a
smaller footprint (API) is better than an overloaded one where the number
of methods could easily explode.  That is smart design.

Additionally, it is not hard to introduce a bit more abstraction if the
parameters might vary by ProxyType.

For example:

setProxy(ProxyConfiguration config)

Where ProxyConfiguration is defined as...

interface ProxyConfiguration {

  ProxyType getType();

}

Then:

interface SniProxyConfiguration extends ProxyConfiguration {

  String getHost();

  int getPort();

}

Food for thought,

-j


On Mon, Mar 9, 2020 at 11:21 AM Dan Smith  wrote:

> > What is your thinking about using the enum vs specific named API’s (e.g.
> setPoolProxyWithSNI).
>
> I think the nice thing about the enum is over separate methods is that it's
> strongly typed, but it might still allow us to support additional proxy
> types in the future with less modifications for code that wraps the API
> (eg, cache.xml), or Spring Data Geode. It also makes it clear you can only
> set one type of proxy.
>
> +1 to what Bill said. I could be convinced to use setProxy(ProxyType,
> String host, int port) however.
>
> -Dan
>
>
> On Mon, Mar 9, 2020 at 10:54 AM Bill Burcham 
> wrote:
>
> > By popular demand we are extending the RFC review period. I know Udo
> asked
> > for Friday (and Joris +1'd it), but since this is a small RFC, we'd like
> to
> > try to close it by Wednesday, March 11, ok?
> >
> > On Mon, Mar 9, 2020 at 10:39 AM Jacob Barrett 
> wrote:
> >
> > > I raised similar concerns as a comment in the RFC.
> > >
> > > > On Mar 9, 2020, at 10:29 AM, Anthony Baker 
> wrote:
> > > >
> > > > Given this new API:
> > > >
> > > >setPoolProxy(ProxyType type, String proxyAddress)
> > > >
> > > > The ProxyType enum seems to be a look ahead at supporting other kinds
> > of
> > > proxies.  What is your thinking about using the enum vs specific named
> > > API’s (e.g. setPoolProxyWithSNI).
> > > >
> > > > Currently the definition of the proxyAddress seems to be dependent of
> > > the proxy type.  Did you consider stronger typing using an URI
> parameter
> > > type?
> > > >
> > > > Anthony
> > > >
> > > >
> > > >
> > > >> On Mar 6, 2020, at 11:04 AM, Bill Burcham 
> > > wrote:
> > > >>
> > > >> Please review the RFC for *Client side configuration for a SNI
> proxy*:
> > > >>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> > > >>
> > > >> Please comment by Monday, March 9, 2020.
> > > >>
> > > >> Regards,
> > > >> Bill and Ernie
> > > >
> > >
> >
>


-- 
-John
Spring Data Team

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum]

By sticking to the "on-demand" patch release process, then there is no
difference to the current release process, and this proposal adds nothing
of value.

On Tue, Mar 3, 2020 at 12:44 AM Aaron Lindsey 
wrote:

> +1 to the proposal as it’s written.
>
> I’m not sure about setting regular intervals for patch releases vs
> sticking with our current “on-demand” process. I don’t think this has to be
> spelled out in this proposal. I’d be fine with sticking to “on-demand”
> patch releases as we’ve been doing for now and seeing how that goes. If
> needed we could follow that up with a proposal for regular patch release
> intervals.
>
> - Aaron
>
> > On Feb 26, 2020, at 8:45 AM, Anthony Baker  wrote:
> >
> >
> >
> >> On Feb 25, 2020, at 1:42 PM, Udo Kohlmeyer  wrote:
> >>
> >> From the proposal it seems we are departing from the initial delivery
> paradigm of "always upgrade to the latest version, because all fixes are
> going in there", to the more product orientated approach of, there is a
> support lifespan for each {major}-{minor} version. Which is a more
> traditional product approach.
> >>
> >> Is there a specific reason we advocating for moving away from "the fix
> will be in the latest release X:Y:Z" ?
> >>
> >
> > From the proposal:
> >
> > "The Geode project has been following a model of shipping releases
> quarterly [1][2].  Using the SemVer [3] approach, these quarterly releases
> are labeled as minor versions.  Occasionally, the project has shipped patch
> releases [4] to address security vulnerabilities or really critical bugs.
> However, on the whole the project has asked users to wait until the next
> quarterly minor release to receive improvements and fixes.
> >
> > It would benefit our user community if we supported our releases for a
> period of time by back porting important fixes and providing patch
> releases.”
> >
> > I believe that taking this approach will clarify expectations and make
> it easier for users to rely on Geode for their projects.
> >
> >
> >> The current methodology or the community voting on changes being
> cherry-picked is related to fixes making it into an unreleased version of
> Geode. From the proposal, are we advocating for extra voting "Do we include
> fix GEODE-, into N , N-1 or N-2? " This does seem to be something that
> might be more work for the community, rather than just updating to latest
> RELEASE. Or is the suggestion that closer to each release period, a list of
> candidate tickets are proposed for back porting? Or is the back porting and
> vote on inclusion done based on discretion and on a ticket by ticket basis?
> >
> > I think the process will follow our approach to back porting fixes onto
> a release branch:
> >
> > 1) When you fix an “important” issue, note that it will need to be back
> ported onto the correct set of support branches.
> > 2) The assigned release manager for the support branch will coordinate
> community consensus and help with cherry-picking the change as well as
> ensuring the pipelines are staying green.
> >
> >>
> >> With the reduced scope of supported versions, does this also mean we
> reduce scope of backward compatibility testing between versions? i.e can we
> now change our backward compatibility testing to mimic the same behavior
> where we only test compatibility between, HEAD,N,N-1 and N-2?
> >>
> >
> > Great question.  I think we continue to follow our SerVer approach to
> naming versions, as well as following the backwards compatibility
> guidelines described in [1[.  In short, I don’t think this N-2 changes our
> requirements—this idea is more about what versions we will patch.
> >
> >
> > Anthony
> >
> > [1]
> https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility
> >
> >
> >
> >
> >> --Udo
> >>
> >> On 2/25/20 11:51 AM, Alexander Murmann wrote:
> >>> Hi John,
> >>>
> >>> I think what you are calling out in 1. and 2. matches what was
> discussed in
> >>> the proposal and thread. Please call out if you disagree on a detail.
> >>>
> >>> What's your reasoning behind 3?
> >>> I see little reason to ship a patch release (which is significant
> work) if
> >>> there was no important fix.
> >>> Likewise I am concerned about waiting to ship a critical fix to our
> users
> >>> or leave them with gaping security vulnerabilities when we have a fix,
> but
> >>> the next patch releas

Re: [DISCUSSION] - ClassLoader Isolation

[John Blum]

Bruce - The primary gist of it is, client applications do not use the
preconfigured classpath determined by Geode itself, such as would be the
case when you start servers using *Gfsh*.  Clients are not started with
*Gfsh*, or any other Geode script for that matter.

On Thu, Feb 27, 2020 at 8:53 AM Udo Kohlmeyer  wrote:

> @Bruce, Thank you for bringing this up. The first iteration of this
> would specifically target only the server-side. BUT, I do agree, that
> clients could suffer similar problems. Yet, from experience, I (and many
> other users) have deployed different versions of the Spring Framework
> (compared to Geode) with success.
>
> Generally it is easier to resolve client-side dependencies than server,
> as one has more control over the client than a deployed (managed) server
> instance.
>
> But if we think that there is a specific scenario that a client is
> suffering from, I would be more than happy to make sure that this is
> rolled out to the client shortly after having delivered it into the server.
>
> --Udo
>
> On 2/27/20 8:45 AM, Bruce Schuchardt wrote:
> > Udo, how does this relate to the client cache?  I assume people have the
> same problems with dependencies in client-cache applications that they have
> in functions that they deploy on a server-cache.
> >
> > On 2/26/20, 10:10 AM, "Udo Kohlmeyer"  wrote:
> >
> >  Hi there Geode Dev's.
> >
> >  There is a new RFC proposal on ClassLoader Isolation. The review end
> >  date is 13 Feb 2020.
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation
> >  <
> https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation>
> >
> >  Please review and discuss in this thread.
> >
> >  --Udo
> >
> >
> >
> >
>


-- 
-John
Spring Data Team

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum]

NOTE: Sorry Udo, you caught me mid-flight in my response to Alexander...

Alexander-

Certainly there are circumstances (e.g. Security vulnerabilites) which may
warrant a patch/maintenance release sooner than 6 weeks, along with other
circumstances may cause a release to take longer than 6 weeks, if
"important" changes, as called out in #2, take a bit longer to complete
than expected.

Sometimes this might be dictated by upstream dependencies as well (e.g.
Apache Lucene).  You should take the 6 week window to mean a general
guideline, and not an absolute, in order to have predictability so users
can plan upgrades, even for patch releases, which is the best interest of
everyone to stay current with.

I would find it unlikely that there would not be a need for regular patches
~every 6 weeks to N, N-1 and N-2 versions.  This is not to say is "always"
going to be "important" changes, but I suspect most of the time, certain
things probably can and should be backported, regardless of "our workload
effort" that I am quite certain our users are not as concerned about.

-j

On Tue, Feb 25, 2020 at 1:42 PM Udo Kohlmeyer  wrote:

>  From the proposal it seems we are departing from the initial delivery
> paradigm of "always upgrade to the latest version, because all fixes are
> going in there", to the more product orientated approach of, there is a
> support lifespan for each {major}-{minor} version. Which is a more
> traditional product approach.
>
> Is there a specific reason we advocating for moving away from "the fix
> will be in the latest release X:Y:Z" ?
>
> The current methodology or the community voting on changes being
> cherry-picked is related to fixes making it into an unreleased version
> of Geode. From the proposal, are we advocating for extra voting "Do we
> include fix GEODE-, into N , N-1 or N-2? " This does seem to be
> something that might be more work for the community, rather than just
> updating to latest RELEASE. Or is the suggestion that closer to each
> release period, a list of candidate tickets are proposed for back
> porting? Or is the back porting and vote on inclusion done based on
> discretion and on a ticket by ticket basis?
>
> With the reduced scope of supported versions, does this also mean we
> reduce scope of backward compatibility testing between versions? i.e can
> we now change our backward compatibility testing to mimic the same
> behavior where we only test compatibility between, HEAD,N,N-1 and N-2?
>
> --Udo
>
> On 2/25/20 11:51 AM, Alexander Murmann wrote:
> > Hi John,
> >
> > I think what you are calling out in 1. and 2. matches what was discussed
> in
> > the proposal and thread. Please call out if you disagree on a detail.
> >
> > What's your reasoning behind 3?
> > I see little reason to ship a patch release (which is significant work)
> if
> > there was no important fix.
> > Likewise I am concerned about waiting to ship a critical fix to our users
> > or leave them with gaping security vulnerabilities when we have a fix,
> but
> > the next patch release train doesn't depart for several weeks.
> >
> > On Tue, Feb 25, 2020 at 11:41 AM John Blum  wrote:
> >
> >> Real quick thought... IMO:
> >>
> >> 1. There should be patch (maintenance) releases for each major.minor,
> up to
> >> N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3
> >> where N-3 is no longer supported.
> >> 2. All important changes should be backported.  I say "important"
> loosely
> >> since that should be decided by the community, but in general, that
> means
> >> Blocker, Critical, Security fixes or other changes that can impact the
> >> contract, functionality or proper behavior of Apache Geode in whatever
> >> context.
> >> 3. Patch (maintenance) releases should occur at a regular, "predictable"
> >> intervals (e.g. every 6 weeks), not on an adhoc basis.
> >>
> >> $0.02
> >> -John
> >>
> >>
> >> On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann  >
> >> wrote:
> >>
> >>>> Or, we could emphasize the shift in process with bigger changes:
> >>>> i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> >>>> "support/1.13"
> >>>> ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> >>>> instead create "apache-release-1-13-main"
> >>>> iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> >>>> released, we could keep it around for 9 months a

Re: [DISCUSS] RFC: Shipping Geode patch releases

[John Blum]

Real quick thought... IMO:

1. There should be patch (maintenance) releases for each major.minor, up to
N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3
where N-3 is no longer supported.
2. All important changes should be backported.  I say "important" loosely
since that should be decided by the community, but in general, that means
Blocker, Critical, Security fixes or other changes that can impact the
contract, functionality or proper behavior of Apache Geode in whatever
context.
3. Patch (maintenance) releases should occur at a regular, "predictable"
intervals (e.g. every 6 weeks), not on an adhoc basis.

$0.02
-John


On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann 
wrote:

> >
> > Or, we could emphasize the shift in process with bigger changes:
> > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> > "support/1.13"
> > ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> > instead create "apache-release-1-13-main"
> > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> > released, we could keep it around for 9 months and re-use it for
> collecting
> > patches and making patch releases during that time.
> >
> +1 I cannot see any argument against cutting a release branch for the minor
> version and keeping it around.
>
> The community process around deciding how long to gather fixes before
> > shipping a patch release isn’t any easier either way.
>
> How about we wait for someone to call out the need to ship a patch
> release.  At
> that point we use the rule of thumb "aim for no more than 1 patch release
> per minor per month" to guide our community discussion.
>
> I would like to see more discussion on the community impact of increasing
> > the commitment required of a release manager.  In the short term it would
> > be good for Geode to have someone focused on improving the release
> process
> > for a longer period of time than a single release.  But in the long term,
> > people may be less likely to volunteer, and release experience will be
> > concentrated in fewer members of the community...
>
> Are there more things that could be automated? When I filled the role ~1
> year ago there was lots of copying and pasting of scripts and I even wrote
> one to help validate fixVersions. Although release process automation
> should probably be taken to a different discussion, since it's mostly
> separate form Anthony's proposal.
>
>
> On Tue, Feb 25, 2020 at 11:06 AM Owen Nichols  wrote:
>
> > These concerns make sense.  We could satisfy them within our existing
> > “on-demand” process:
> >
> > 1) the first time there is a change to backport to support branches,
> > propose the patch release.  Now we have a branch.  Decide as a community
> > how urgently it needs to be released vs how long to hold it open for
> other
> > potential fixes.
> >
> > Or, we could emphasize the shift in process with bigger changes:
> > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> > "support/1.13"
> > ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> > instead create "apache-release-1-13-main"
> > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> > released, we could keep it around for 9 months and re-use it for
> collecting
> > patches and making patch releases during that time.
> >
> > The community process around deciding how long to gather fixes before
> > shipping a patch release isn’t any easier either way.
> >
> > One advantage of our current process is that a release doesn’t happen
> > until someone volunteers to make it happen.  We can do as many or as few
> > patch releases as the community is willing -- a release always has a
> > champion.
> >
> > I would like to see more discussion on the community impact of increasing
> > the commitment required of a release manager.  In the short term it would
> > be good for Geode to have someone focused on improving the release
> process
> > for a longer period of time than a single release.  But in the long term,
> > people may be less likely to volunteer, and release experience will be
> > concentrated in fewer members of the community...
> >
> >
> > > On Feb 25, 2020, at 9:29 AM, Anthony Baker  wrote:
> > >
> > > Here’s a couple things I’d like to avoid:
> > >
> > > 1) Issuing a patch release for every single commit that we back port
> > onto a supported minor version.  This seems like a high cost approach.
> Of
> > course, some issues may be important enough to require that.
> > >
> > > 2) Merging a change to develop, and then having to come back weeks
> later
> > and back porting the change to a release branch.  It just seems less
> > optimal since I’ll have lost the context on the changes, particularly if
> > the cherry-pick is non-trivial.
> > >
> > > More comments below.
> > >
> > > Anthony
> > >
> > >
> > >> On Feb 24, 2020, at 2:16 PM, Owen Nichols 
> wrote:
> > >>
> > >> Hi Alexander, currently we don’t start a patch 

Re: OQL Method Authorizer Blog

[John Blum]

+1 Good read, Juan.  Nice job!

On Fri, Feb 14, 2020 at 9:59 AM Jason Huynh  wrote:

> Great job Juan!  Very informative and detailed read.
>
> On Fri, Feb 14, 2020 at 4:43 AM Nabarun Nag  wrote:
>
> > Hi Geode Community,
> >
> > Please do visit the blog that Juan Ramos has put up on the OQL Method
> > Authorizer :
> >
> >
> https://jujoramos.blogspot.com/2020/02/pluggable-oql-method-authorization.html
> >
> > Thank you Juan for this effort.
> >
> > Regards
> > Nabarun Nag
> >
>


-- 
-John
Spring Data Team

Re: [Vote] Include GEODE-7752 into 1.12

[John Blum]

+1

On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson 
wrote:

> +1
>
> On 2/5/20, 1:53 PM, "Udo Kohlmeyer"  wrote:
>
> Hi there Geode dev,
>
> I would like to request that GEODE-7752
> (7028f601680fee3f57cbdff63951128d7180ca13) gets included into 1.12.
>
> This piece of code is a refactor of work done in GEODE-7715. This
> refactor specializes Builders and simplifies Builder behavior for
> better
> user experience.
>
> --Udo
>
>
>
>

-- 
-John
Spring Data Team

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[John Blum]

I thought I recall that the IndexType

[1]
was *deprecated* in favor of specific methods on the QueryService

interface
[2] used to create Indexes of a specific type, e.g. like a Key Index using
QueryService.createKeyIndex(..)

[3]
(or one of the "overloaded" variants), which is in contrast to the generic
createIndex(..)

method [4] that accepted the (now deprecated) IndexType Enum as an argument.

However, I still feel that the IndexType Enum should NOT be deprecated,
especially given that the Index.getType():IndexType

method [5] is quite useful to assess an Index (e.g. think
Management/Monitoring tools or other analysis tools to ascertain the
state/configuration of the system).

-j


[1]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
[2]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html
[3]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createKeyIndex-java.lang.String-java.lang.String-java.lang.String-
[4]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createIndex-java.lang.String-org.apache.geode.cache.query.IndexType-java.lang.String-java.lang.String-java.lang.String-
[5]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/Index.html#getType--


On Thu, Jan 2, 2020 at 1:26 PM Joris Melchior  wrote:

> Hi Kirk,
>
> No, I've tried to figure that out but was unsuccessful in doing so. It
> would be helpful if someone would be able to shed some light on that.
>
>
> On Thu, Jan 2, 2020 at 1:34 PM Kirk Lund  wrote:
>
> > Hi Joris, I've read the proposal and reviewed the code some. It's not
> clear
> > to me why it was originally deprecated or what the intended new direction
> > (instead of IndexType) was ever going to be. Do you know more about why
> it
> > was deprecated or what the devs were going to replace it with?
> >
> > On Thu, Jan 2, 2020 at 6:31 AM Joris Melchior 
> > wrote:
> >
> > > Apart from Bruce's response (thanks!) it's been very quiet on this
> item.
> > >
> > > I'll extend the response time to Jan 10.
> > >
> > > Details at
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> > >
> > > Thanks, Joris.
> > >
> > > On Wed, Dec 4, 2019 at 1:03 PM Bruce Schuchardt <
> bschucha...@pivotal.io>
> > > wrote:
> > >
> > > > This proposal seems reasonable to me
> > > >
> > > > On 12/3/19 10:19 AM, Joris Melchior wrote:
> > > > > Ah, that makes sense. I will update!
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann <
> > amurm...@pivotal.io
> > > >
> > > > > wrote:
> > > > >
> > > > >> Joris, the "to be reviewed by" field is for a target date by which
> > to
> > > > wrap
> > > > >> up the discussion. Do you mind updating the field and letting the
> > > > mailing
> > > > >> list know what timeframe you envision?
> > > > >>
> > > > >> Thanks!
> > > > >>
> > > > >> On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior <
> jmelch...@pivotal.io
> > >
> > > > >> wrote:
> > > > >>
> > > > >>> Hi All,
> > > > >>>
> > > > >>> Looking for feedback on the proposal to [un/de]deprecate the
> > > IndexType
> > > > >> ENUM
> > > > >>> on Geode.
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> > > > >>> Thanks, Joris.
> > > > >>>
> > > > >>> --
> > > > >>> *Joris Melchior *
> > > > >>> CF Engineering
> > > > >>> Pivotal Toronto
> > > > >>> 416 877 5427
> > > > >>>
> > > > >>> “Programs must be written for people to read, and only
> incidentally
> > > for
> > > > >>> machines to execute.” – *Hal Abelson*
> > > > >>> 
> > > > >>>
> > > > >
> > > >
> > >
> > >
> > > --
> > > *Joris Melchior *
> > > CF Engineering
> > > Pivotal Toronto
> > > 416 877 5427
> > >
> > > “Programs must be written for people to read, and only incidentally for
> > > machines to execute.” – *Hal Abelson*
> > > 
> > >
> >
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> 

Re: [DISCUSS] What should we do with @Ignore tests?

[John Blum]

+1 to Kirk's comments.

Also, regarding (c), using AssumeThat [1] (or, alternatively & IMO
preferrably, [2]) might provide some temporary relief.


[1] https://junit.org/junit4/javadoc/latest/org/junit/Assume.html
[2]
https://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/Assumptions.html


On Thu, Jan 2, 2020 at 11:46 AM Kirk Lund  wrote:

> The Geode code base has 328 tests across 145 files with @Ignore. The vast
> majority of these were disabled pre-Geode because the previous group's
> policy was to disable any test that failed in CI, then file a bug system
> ticket, fix it, and re-enable it. However, the process never followed
> through beyond disabling the test and filing a ticket. Since that was the
> old pre-Apache bug system, most of us don't have access to it.
>
> From a Pivotal point-of-view, it's possible that every Geode commit that
> passes precheckin but then breaks a Pivotal Hydra test could have been
> caught by one of those disabled tests. So we are probably already
> experiencing pain and paying the price for not re-enabling these tests (in
> at least some cases).
>
> @Ignore was introduced in JUnit 4, but most of these tests were JUnit 3
> style. After I upgraded us to JUnit 4, I found every JUnit 3 style of test
> that had been disabled by renaming the test, fixed the name of the test,
> and added @Test plus @Ignore so that we can at least be aware of how many
> tests are disabled and actively search for them. I tried to add include a
> comment in the annotation if I could figure out why it was disabled. Some
> of these comments are things like (a) TRAC ticket # if known, (b) not yet
> implemented, (c) skip test for this configuration, (d) not yet implemented
> for partitioned region, etc. Sometimes I just reused a java comment that
> the disabler left above the disabled test.
>
> More info on some of those @Ignore comments:
>
> (b) not yet implemented -- this means probably means the test was never
> finished and should just be deleted but it might also be another example of
> (c) or (d) in certain test classes
>
> (c) skip test for this configuration -- this is a class that extends
> another test class but one or more test methods are overridden with @Ignore
> to prevent the test from running in the subclass because it's invalid for
> that configuration -- we can't just delete these, we have to remove
> class-hierarchy (stop extending test classes!) which will result in some
> redundancy between two test classes
>
> I do not think we should blindly delete them all, and I think we need to
> spend time studying each one individually to determine what the state of
> the test is and what should be done for it. So even if many in our
> community want to just delete all tests with @Ignore, that's not going to
> work in at least half of the test classes. You'll have to tease apart
> sub-classes from super-classes.
>
> Plus you won't actually know that the test has other coverage unless you
> spend the time analyzing it, which is what I think we should do.
>
> Some quick examples:
>
> *1) ClientServerTimeSyncDUnitTest*
>
> Notes: this test class has only two tests and both are @Ignored, so maybe
> deleting them isn't the best answer.
>
> testClientTimeAdvances is marked with @Ignore("Bug 52327"). #52327 is
> "ClientServerTimeSyncDUnitTest.testClientTimeAdvances fails intermittently"
>
> testClientTimeSlowsDown is marked with @Ignore("not yet implemented") which
> either means the test was never finished or the functionality it's trying
> to test was never finished in the product code. It looks like the test
> never had any assertions.
>
> Personally, I don't think I'd want to delete either of these tests. I would
> prefer to fix them up.
>
> If we really care about Apache Geode, our test coverage, and the quality of
> the product, then I think we should separate super-sub classes that force
> us to disable test in sub-class that are invalid test cases and fix analyze
> each test on a case-by-case basis to determine what should be done. And I
> believe that the default approach for each test should be to fix it rather
> than delete it.
>
> *2) DistributedAckPersistentRegionCCEDUnitTest*
>
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckPersistentRegionCCEDUnitTest.java:41:
>  @Ignore("Skip test for this configuration")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckPersistentRegionCCEDUnitTest.java:46:
>  @Ignore("Skip test for this configuration")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckPersistentRegionCCEDUnitTest.java:51:
>  @Ignore("Skip test for this configuration")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckRegionCCEDUnitTest.java:110:
>  @Ignore("replicates don't allow local destroy")
>
> geode-core/src/distributedTest/java/org/apache/geode/cache30/DistributedAckRegionCCEDUnitTest.java:117:
>  @Ignore("replicates don't allow local 

Re: [VOTE] Inclusion of GEODE-7531 into 1.11

[John Blum]

+1

On Tue, Dec 17, 2019 at 3:25 PM Dick Cavender  wrote:

> +1
>
> On Tue, Dec 17, 2019 at 3:03 PM Patrick Johnson 
> wrote:
>
> > +1
> >
> > > On Dec 17, 2019, at 3:01 PM, Owen Nichols  wrote:
> > >
> > > +1
> > >
> > >> On Dec 17, 2019, at 2:57 PM, Udo Kohlmeyer  wrote:
> > >>
> > >> Hi there Apache Devs.
> > >>
> > >> I can we please vote on the inclusion of GEODE-7531. This issue is to
> > fix an bug which assumes that all `Pool` objects are of type `PoolImpl`
> and
> > immediately casts Pool -> PoolImpl.
> > >>
> > >> In the case of testing with Mocks, the type casts fail, because the
> > Pool-mocks are not of type PoolImpl. The simplest fix (for now) was to
> type
> > check before the cast.
> > >>
> > >>
> > >> Regards
> > >>
> > >> Udo
> > >>
> > >
> >
> >
>


-- 
-John
Spring Data Team

Re: [VOTE] Inclusion of GEODE-7159 into 1.11

[John Blum]

+1

On Tue, Dec 17, 2019 at 3:25 PM Dick Cavender  wrote:

> +1
>
> On Tue, Dec 17, 2019 at 3:01 PM Patrick Johnson 
> wrote:
>
> > +1
> >
> > > On Dec 17, 2019, at 2:59 PM, Owen Nichols  wrote:
> > >
> > > +1
> > >
> > >> On Dec 17, 2019, at 2:58 PM, Udo Kohlmeyer  wrote:
> > >>
> > >> Hi there Apache Devs.
> > >>
> > >> I can we please vote on the inclusion of GEODE-7159. This issue is to
> > fix an bug which assumes that all `Pool` objects are of type `PoolImpl`
> and
> > immediately casts Pool -> PoolImpl. This issue is related to GEODE-7531,
> > and is specific to the emergencyClose method.
> > >>
> > >> In the case of testing with Mocks, the type casts fail, because the
> > Pool-mocks are not of type PoolImpl. The simplest fix (for now) was to
> type
> > check before the cast.
> > >>
> > >>
> > >> Regards
> > >>
> > >> Udo
> > >>
> > >
> >
> >
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

If you must know, there are important test cases in both SBDG and SSDG to
be able to register (and subsequently unregister) the "mock" Pool with the
PoolManager, which unfortunately is a consequence of the SDG
PoolFactoryBean's design being reliant on the PoolManager (to resolve the
Pool), and to some extent, the PoolFactory API (to create the Pool)  in the
first place.  Of course, there is no other way to "resolve" a reference to
a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.

Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
Apache Geode's public API was properly maintained and evolved to address a
new use cases.  For example (and again), see GEODE-7532
 [1].

It turns out, there are many, many cases like GEODE-7532
 [1], with classes and
methods containing useful functions buried deep down inside Geode
"internal" packages.  The o.a.g.distributed.internal.MemberListener
interface comes to mind.  It is not difficult to see how his interface
would be useful in both frameworks & tooling (e.g. for management &
monitoring).

Or, how about the poor resource management/cleanup Apache Geode fails to do
properly w.r.t. SSL Sockets, that STDG now needs to account for

[2]
when running automated integration tests.

I think there was another example
 [3] recently, which STDG
must account for  [4] as
well.

Serializer registration/unregistration is yet another area.  The laundry
list is quite long!

The whole notion of Apache Geode's "internal" API is horribly broken,
especially when the public API often comes up short.

What troubles me is that we see the recommended changes in GEODE-7532 as a
"bandaid".  Really?

It does not matter whether these classes are "internal" or not, nor whether
they are used (externally) or not, so long as they are used properly.  If
they are "public" there is simply no guarantee they won't be used, and you
cannot expect "internal" problems to not have external consequences.

SIDE NOTE: Of course, this is further predicated on the fact those
"internal" classes were designed/implemented correctly in the first place,
which they also, were not!

I down voted for several reasons:

1. First, YES, because this blocks SBDG from moving to Apache Geode 1.11,
and perhaps, more importantly...
2. Because the Pool management in PoolManagerImpl A) refers to the Pool as
PoolImpl despite taking a reference to Pool, and B) exposes the
implementation of the usage tracking logic (which is a clear violation of
"encapsulation" and a series code smell)
3. And because the IllegalStateException message is not accurate nor was it
very informative (e.g. "what Regions").
4. Or because 2A by (along with GEODE-7159
 [5]) will most
definitely cause problems for us later, especially since these problems
will be time delayed (invoked during resource cleanup) making them hard to
pinpoint and very confusing to users.

Also, imagine a scenario where Geode offers different Pool implementations,
beyond PoolImpl.  Why else would Geode provide a PoolFactory interface if
not to encapsulate creation, configuration and initialization of different
types of Pools part of that *Open/Closed* principle.  There is no point
to have a PoolFactory otherwise since the PoolManager could have simply
created Pools.  Ironically, the PoolFactory is not something that is used
in this way and therefore became an unnecessary layer of indirection.  #sigh

In addition, the recommended changes in GEODE-7531 are not invasive
what-so-ever, and will not adversely affect Geode 1 way or another.

In closing, anytime the overall code quality of Geode comes into question
(and there is a lot to question with this codebase), which can, and most
likely will affect our end-users experience, and it HAS and DOES, you
better believe and I am going to call this out.

-j


[1] https://issues.apache.org/jira/browse/GEODE-7532
[2]
https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
[3] https://markmail.org/message/5juxxnkttzjndidg
[4] https://markmail.org/message/5juxxnkttzjndidg
[5] https://issues.apache.org/jira/browse/GEODE-7159

On Wed, Dec 4, 2019 at 6:12 PM Robert Houghton  wrote:

> @udo, if one needs to use a strong word like 'offender', then the offender
> is the one using an internal API. Geode is under no obligation to maintain
> or "fix" these for any project.
>
> Is there a Jira, github issue, or pull-request to promote the internal

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

See comment
<https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282>
[1]
on ticket, GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531>
 [2].

Quite frankly the reasons STDG (or dependent projects downstream like SDG,
SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
articulated in the description of GEODE-753.

[1]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282
[2] https://issues.apache.org/jira/browse/GEODE-7531

On Wed, Dec 4, 2019 at 4:06 PM Dan Smith  wrote:

> On Wed, Dec 4, 2019 at 2:11 PM John Blum  wrote:
>
> > This is not a test failure in SDG.  SDG builds fine with Apache Geode
> 1.11
> > (and all tests pass), as I indicated above in my origin +0 vote.
> >
> > This is a definitive problem for SBDG when using STDG to mock Apache
> Geode
> > resources/objects, which is caused by GEODE-7531.
> >
>
> Hmm, looks like STDG is also using an internal API to inject a mock into
> the PoolManager singleton:
>
> https://github.com/spring-projects/spring-test-data-geode/blob/9a091376528cd79c978bc5b3019d30256fcf3fd5/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/mock/GemFireMockObjectsSupport.java#L1750
>
> Maybe it would be better to fix that? I don't think injecting anything into
> Geode singletons is a good approach - it will likely lead to mysterious
> errors in future tests. And using internal APIs tends to result in breakage
> while upgrading, as evidenced here.
>
> A more complete fix to Geode might be deprecate the static PoolManager
> entirely and move the pool management functionality to ClientCache. That
> might make it easier for you to mock the whole system? In the short term
> perhaps SDG, STDG, etc. can wrap the PoolManager in something that can have
> a mock injected into it, without using internal APIs?
>
> -Dan
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

This is not a test failure in SDG.  SDG builds fine with Apache Geode 1.11
(and all tests pass), as I indicated above in my origin +0 vote.

This is a definitive problem for SBDG when using STDG to mock Apache Geode
resources/objects, which is caused by GEODE-7531.

Either way, the design/code changes made in GEODE-6759 were poor and should
be fixed regardless which GEODE-7531 describes.

-j


On Wed, Dec 4, 2019 at 2:04 PM Dan Smith  wrote:

> On Wed, Dec 4, 2019 at 11:16 AM John Blum  wrote:
>
> > I am changing my vote to -1!
> >
> > I have filed GEODE-7531 <
> https://issues.apache.org/jira/browse/GEODE-7531>
> > [1],
> > which is a serious blocking issue for all things *Spring* for Apache
> > Geode.  This issue alone is currently preventing me from upgrading
> *Spring
> > Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> > SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> > Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
> soon
> > to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
> >
>
>
> I commented on the above JIRA. While we definitely don't want to break
> spring data geode, it looks like maybe the issue is just with one unit test
> in Spring Data Geode using an internal geode API to inject something into a
> singleton? If that's the case, I think it would be better to fix that one
> test in SDG.
>
> -Dan
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

I am changing my vote to -1!

I have filed GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531> [1],
which is a serious blocking issue for all things *Spring* for Apache
Geode.  This issue alone is currently preventing me from upgrading *Spring
Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
to be upgraded to 1.11 once this issue is resolved and 1.11 is available.

If you need further explanation, you don't need to look any further than
the description as well as my comment
<https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096>
 [2].

-j

[1] https://issues.apache.org/jira/browse/GEODE-7531
[2]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096


On Wed, Dec 4, 2019 at 9:24 AM John Blum  wrote:

> Indeed, both dependencies (geode-logging & geode-serialization) are
> listed as runtime dependencies.
>
> *> Is SDG creating its dependencies manually?*
>
> I am not quite following your thinking on this question.  Of course SDG
> uses transitive dependencies. SDG must declare direct dependencies on
> geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
> features API to implement the functionality provided by SDG.
>
> Anyway, it because Apache Geode's public API is broken/incomplete
> (especially from a framework/tooling perspective, but even an application
> perspective in many cases) that SDG must rely on certain (non-protected)
> "internal" APIs.  It turns out that those "internal" classes have hard
> (i.e. compile-time) dependencies on geode-logging & geode-serialization
> to even build a project (application, framework or otherwise) using those
> classes with Apache Geode.
>
> I am currently exploring whether I can alter the use of the "internal"
> class(es) to avoid forcing a compile-time dependency.
>
> -j
>
>
> On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett  wrote:
>
>>
>>
>> > On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
>> >
>> > After some modifications to Spring Data for Apache Geode (Spring Data
>> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
>> >
>> > While I support the modularization effort, I would make it very clear
>> (in
>> > documentation) now that both geode-logging and geode-serialization are
>> > required on the application classpath when using Apache Geode.
>> >
>> > Technically, I am not entirely certain about geode-serialization (yet),
>> but
>> > geode-logging is strictly required to use Apache Geode.  I need to run
>> some
>> > more tests.
>>
>> Both are properly listed as runtime scope in the geode-core POM. Is SDG
>> creating its dependencies manually or using the transitive dependencies
>> from the Geode POMs?
>>
>> -Jake
>>
>>
>>
>>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
Spring Data Team

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

Indeed, both dependencies (geode-logging & geode-serialization) are listed
as runtime dependencies.

*> Is SDG creating its dependencies manually?*

I am not quite following your thinking on this question.  Of course SDG
uses transitive dependencies. SDG must declare direct dependencies on
geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
features API to implement the functionality provided by SDG.

Anyway, it because Apache Geode's public API is broken/incomplete
(especially from a framework/tooling perspective, but even an application
perspective in many cases) that SDG must rely on certain (non-protected)
"internal" APIs.  It turns out that those "internal" classes have hard
(i.e. compile-time) dependencies on geode-logging & geode-serialization to
even build a project (application, framework or otherwise) using those
classes with Apache Geode.

I am currently exploring whether I can alter the use of the "internal"
class(es) to avoid forcing a compile-time dependency.

-j


On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett  wrote:

>
>
> > On Dec 1, 2019, at 2:40 PM, John Blum  wrote:
> >
> > After some modifications to Spring Data for Apache Geode (Spring Data
> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
> >
> > While I support the modularization effort, I would make it very clear (in
> > documentation) now that both geode-logging and geode-serialization are
> > required on the application classpath when using Apache Geode.
> >
> > Technically, I am not entirely certain about geode-serialization (yet),
> but
> > geode-logging is strictly required to use Apache Geode.  I need to run
> some
> > more tests.
>
> Both are properly listed as runtime scope in the geode-core POM. Is SDG
> creating its dependencies manually or using the transitive dependencies
> from the Geode POMs?
>
> -Jake
>
>
>
>

-- 
-John
john.blum10101 (skype)

Re: IndexType deprecation question

[John Blum]

My vote would be to UNDEPRECATE the IndexType in Apache Geode.  There are
several codepaths in SDG that use the IndexType to make certain decisions.

I also think having an Enum is much more flexible than having a method per
Index type, particularly since you can use Enum values in switch
statements.  I do like the createXyzIndex methods (e.g. createKeyIndex) for
common OQL Indexes, however.  I do think the createIndex for
FUNCTIONAL/RANGE OQL Indexes should be renamed (rather, the old method
deprecated and a new method introduced, i.e. createRangeIndex or
createFunctionalIndex).

-j


On Mon, Dec 2, 2019 at 9:44 AM Jason Huynh  wrote:

> Hi Joris,
>
> Just some guesses and no actual answer from me here:
>
> The deprecation of the index type was before HASH indexes were created, and
> my guess was due to the introduction of the "new at the time" query service
> apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService} for
> changes.)
>
> The internals still use the IndexType as you have pointed out and maybe the
> deprecation was more intended for the end user (since it's not an internal
> type) and perhaps it was intended to have been moved internal at some
> point?
>
> There is some weirdness with the index types and actually having multiple
> implementations for the Functional type.  Under the covers we create a
> memory-optimized version based on the indexed expression.
>
> Things have changed since deprecation, so maybe it should be
> un/de-deprecated or an alternative solution can probably be thought up...
>
> -Jason
>
>
> On Mon, Dec 2, 2019 at 9:13 AM Joris Melchior 
> wrote:
>
> > Hi Jason,
> >
> > At this point it is not about creating but returning the Region with an
> > indicator in the management API without using deprecated parts. Under the
> > covers the QueryService java api still uses the IndexType ENUM and had
> > assumed that an alternative would be provided when something is marked as
> > deprecated.
> >
> > I can of course create a new ENUM to return but prefer not to take this
> > step before ensuring that we don't have something in place already.
> >
> > I'm also wondering if the deprecation should have been limited to the
> HASH
> > type on the IndexType ENUM instead of deprecating the complete ENUM.
> >
> > Thanks, Joris.
> >
> > On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:
> >
> > > Hi Joris,
> > >
> > > How are you creating the index?  If using the QueryService java api,
> > there
> > > should be createKeyIndex() and createIndex() methods.  These methods
> > should
> > > create the primary key index and the functional index.
> > >
> > > I am not sure if there is an alternative in gfsh... it might still be
> > using
> > > the IndexType enum or something similar.
> > >
> > >
> > >
> > >
> > > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior 
> > > wrote:
> > >
> > > > Thanks John.
> > > >
> > > > I'm trying to use it on the server side for the management API so
> > > > unfortunately the Spring wrapper is not an option. Hopefully someone
> > can
> > > > provide some insight into the deprecation background once all the
> > turkey
> > > > and stuffing has been digested.
> > > >
> > > > On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:
> > > >
> > > > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > > > spring-data-geode), then there is an SDG Index enum type
> > > > > <
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > >
> > > > > [1]
> > > > > wrapping the deprecated Apache Geode Index enum type
> > > > > <
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > > > >
> > > > >  [2].
> > > > >
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > [2]
> > > > >
> > > > >
> > > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/c

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[John Blum]

+0

After some modifications to Spring Data for Apache Geode (Spring Data
Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.

While I support the modularization effort, I would make it very clear (in
documentation) now that both geode-logging and geode-serialization are
required on the application classpath when using Apache Geode.

Technically, I am not entirely certain about geode-serialization (yet), but
geode-logging is strictly required to use Apache Geode.  I need to run some
more tests.

-j


On Tue, Nov 26, 2019 at 11:46 AM Blake Bender  wrote:

> -1 from native client as well, sorry.  RC3 mistakenly picked up an
> unnecessary commit, and left out the crash fix I needed.  If you revert
> commit 5d012199055a9a7657563727f6e26a406b287fc3 and
> cherry-pick 55da853760c200c53568fe2e6549c912ec26cc27, "GEODE-7426: Fixes
> segfault in log message.", native client should be good to go.
>
> Thanks,
>
> Blake
>
>
>
> On Tue, Nov 26, 2019 at 11:35 AM Lynn Hughes-Godfrey <
> lhughesgodf...@pivotal.io> wrote:
>
> > -1: Analyzing a hang that looks similar to GEODE-5307: Hang with servers
> > all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state
> > https://issues.apache.org/jira/browse/GEODE-5307
> >
> > On Mon, Nov 25, 2019 at 9:13 PM Mark Hanson  wrote:
> >
> > > Hello Geode Dev Community,
> > >
> > > This is a release candidate for Apache Geode version 1.11.0.RC3.
> > > Thanks to all the community members for their contributions to this
> > > release!
> > >
> > > Please do a review and give your feedback, including the checks you
> > > performed.
> > >
> > > Voting deadline:
> > > 11AM PST Monday December 2 2019.
> > >
> > > Please note that we are voting upon the source tag:
> > > rel/v1.11.0.RC3
> > >
> > > Release notes:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> > >
> > > Source and binary distributions:
> > > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/
> > >
> > > Maven staging repo:
> > > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > >
> > > GitHub:
> > > https://github.com/apache/geode/tree/rel/v1.11.0.RC3
> > > https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
> > > https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3
> > >
> > > Pipelines:
> > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> > >
> > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > https://github.com/apache/geode/blob/develop/KEYS
> > >
> > > Command to run geode-examples:
> > > ./gradlew -PgeodeReleaseUrl=
> > > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3
> > > -PgeodeRepositoryUrl=
> > > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > > build runAll
> > >
> > > Regards
> > > Mark Hanson
> >
>


-- 
-John
john.blum10101 (skype)

Re: IndexType deprecation question

[John Blum]

FYI... if you are using *Spring Data for Apache Geode* (SDG;
spring-data-geode), then there is an SDG Index enum type

[1]
wrapping the deprecated Apache Geode Index enum type

 [2].



[1]
https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
[2]
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html


On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior  wrote:

> Hi All,
>
> I notice that the ENUM
>
> org.apache.geode.cache.query.IndexType has been deprecated but can't
> find what to use instead of this ENUM if I wanted to use a
> non-deprecated alternative.
>
> I understand that HASH indexes are no longer recommended but the other
> types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> should be able to use them without using deprecated code.
>
> Can anyone tell me how this is accomplished?
>
> Thanks, Joris.
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> 
>


-- 
-John
john.blum10101 (skype)

Re: Cache.close is not synchronous?

[John Blum]

+1 ^ 64!

I found this out the hard way some time ago and is why STDG exists in the
first place (i.e. usability issues, particularly with testing).

On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund  wrote:

> I found a test that closes the cache and then recreates the cache multiple
> times with 2 second sleep between each. I tried to remove the Thread.sleep
> and found that recreating the cache
> throws DistributedSystemDisconnectedException (see below).
>
> This seems like a usability nightmare. Anyone have any ideas WHY it's this
> way?
>
> Personally, I want Cache.close() to block until both Cache and
> DistributedSystem are closed and the API is ready to create a new Cache.
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> at
>
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:945)
> at
>
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1665)
> at
>
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:791)
> at
>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> at
>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
>


-- 
-John
john.blum10101 (skype)

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[John Blum]

1 more thing...

You can provide additional/dedicated support for newer versions (e.g.
Servlet 4.0) without (unduly) sacrificing backwards compatibility.  This is
done by many popular Java frameworks in fact, which also simultaneously
constitute a minimum baseline (e.g. Servlet 3.1).  Be current and
compatible where it makes sense.  Servlet 3.1 is a very powerful and
logical choice at this particular point in time.

FYR...

Apache Tomcat:
https://docs.spring.io/spring-boot-data-geode-build/1.2.x/reference/html5/
Eclipse Jetty:
https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
Undertow:
http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#getting-undertow
... http://undertow.io/



On Fri, Nov 15, 2019 at 2:57 PM John Blum  wrote:

> I would minimally bump it to 3.1 then.  Not only does Servlet 3.1 open up
> more doors (e.g. NIO), but is also implemented by all current Servlet
> Container providers (Tomcat, Jetty, etc).  Additionally, given all the
> Servlet Containers Jens mentioned at the version that started supporting
> Servlet 3.0 are no longer supported, then 3.1 seems like a good/reasonable
> target.
>
> -j
>
> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith  wrote:
>
>> +1 to bumping to servlet 3.0.
>>
>> -Dan
>>
>> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith 
>> wrote:
>>
>> > Seems to me as long as newer Servlet specs do not deprecate
>> > functionality/api that the session module requires AND that the session
>> > module is not missing any important functionality provided by newer
>> Servlet
>> > specs that it's best to base support the oldest Servlet spec that is
>> still
>> > supported by active container versions. As Jens nicely enumerated, this
>> > seems to be Servlet 3.0 right now.
>> >
>> > At least that's the approach that would give the session management
>> > modules the widest audience. I am currently writing a Servlet 4.0 web
>> app
>> > and the Geode session module is working great except that I need to
>> layer
>> > on an additional filter to ensure my session cookies are secure.
>> >
>> >
>> > --
>> >
>> > Charles Smith
>> >
>> > Developer/Analyst
>> >
>> > Web Architecture and Development
>> > MacEwan University
>> > smith...@macewan.ca
>> >
>> >
>> > 
>> > From: John Blum 
>> > Sent: Friday, November 15, 2019 11:17 AM
>> > To: geode 
>> > Subject: Re: Proposal to modify Servlet spec support for the HTTP
>> Session
>> > Management Module for AppServers
>> >
>> > Since the Servlet 3.1 spec is available and the current version is 4.0,
>> why
>> > not consider 3.1 or even 4.0, actually?
>> >
>> > -j
>> >
>> > On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe  wrote:
>> >
>> > > Hello Charles; thanks very much for bringing this up.
>> > >
>> > > I vote +1 on this proposal.
>> > >
>> > > Just to add a bit more details for others:
>> > >
>> > > The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
>> > > versions of various containers that supported it are:
>> > >
>> > >- Jetty 8 (EOL'd since 11/2014) [1]
>> > >- Tomcat 7 (Version 6 EOL'd 2017) [2]
>> > >- JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017)
>> [3]
>> > >- Websphere 8.0 (End of support 4/2018) [4]
>> > >- Weblogic 12cR1 (Extended Support until 12/2019) [5]
>> > >
>> > > The implication is that, of these products, there are *no* currently
>> > > supported versions that *do not* support the Servlet 3.0 spec. I
>> believe
>> > it
>> > > is quite safe for us to indicate that the Session Modules are now only
>> > > supported on 3.0 compliant containers.
>> > >
>> > > --Jens
>> > >
>> > > [1] -
>> > >
>> >
>> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
>> > > [2] - http://tomcat.apache.org/whichversion.html
>> > > [3] - https://access.redhat.com/support/policy/updates/jboss_notes
>> > > [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
>> > > [5] -
>> > >
>> > >
>> >
>> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
>> > >
>> > > On Fri, Nov

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[John Blum]

I would minimally bump it to 3.1 then.  Not only does Servlet 3.1 open up
more doors (e.g. NIO), but is also implemented by all current Servlet
Container providers (Tomcat, Jetty, etc).  Additionally, given all the
Servlet Containers Jens mentioned at the version that started supporting
Servlet 3.0 are no longer supported, then 3.1 seems like a good/reasonable
target.

-j

On Fri, Nov 15, 2019 at 12:49 PM Dan Smith  wrote:

> +1 to bumping to servlet 3.0.
>
> -Dan
>
> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith 
> wrote:
>
> > Seems to me as long as newer Servlet specs do not deprecate
> > functionality/api that the session module requires AND that the session
> > module is not missing any important functionality provided by newer
> Servlet
> > specs that it's best to base support the oldest Servlet spec that is
> still
> > supported by active container versions. As Jens nicely enumerated, this
> > seems to be Servlet 3.0 right now.
> >
> > At least that's the approach that would give the session management
> > modules the widest audience. I am currently writing a Servlet 4.0 web app
> > and the Geode session module is working great except that I need to layer
> > on an additional filter to ensure my session cookies are secure.
> >
> >
> > --
> >
> > Charles Smith
> >
> > Developer/Analyst
> >
> > Web Architecture and Development
> > MacEwan University
> > smith...@macewan.ca
> >
> >
> > 
> > From: John Blum 
> > Sent: Friday, November 15, 2019 11:17 AM
> > To: geode 
> > Subject: Re: Proposal to modify Servlet spec support for the HTTP Session
> > Management Module for AppServers
> >
> > Since the Servlet 3.1 spec is available and the current version is 4.0,
> why
> > not consider 3.1 or even 4.0, actually?
> >
> > -j
> >
> > On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe  wrote:
> >
> > > Hello Charles; thanks very much for bringing this up.
> > >
> > > I vote +1 on this proposal.
> > >
> > > Just to add a bit more details for others:
> > >
> > > The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
> > > versions of various containers that supported it are:
> > >
> > >- Jetty 8 (EOL'd since 11/2014) [1]
> > >- Tomcat 7 (Version 6 EOL'd 2017) [2]
> > >- JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017)
> [3]
> > >- Websphere 8.0 (End of support 4/2018) [4]
> > >- Weblogic 12cR1 (Extended Support until 12/2019) [5]
> > >
> > > The implication is that, of these products, there are *no* currently
> > > supported versions that *do not* support the Servlet 3.0 spec. I
> believe
> > it
> > > is quite safe for us to indicate that the Session Modules are now only
> > > supported on 3.0 compliant containers.
> > >
> > > --Jens
> > >
> > > [1] -
> > >
> >
> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> > > [2] - http://tomcat.apache.org/whichversion.html
> > > [3] - https://access.redhat.com/support/policy/updates/jboss_notes
> > > [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
> > > [5] -
> > >
> > >
> >
> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
> > >
> > > On Fri, Nov 15, 2019 at 8:11 AM Charles Smith 
> > wrote:
> > >
> > > > Hello,
> > > >
> > > > The Geode HTTP Session Management Module for AppServers currently
> > states:
> > > > This approach is a generic solution, which is supported by any
> > container
> > > > that implements the Servlet 2.4 specification.
> > > > I would like to suggest that this official support be bumped up to
> the
> > > > Servlet 3.0 specification.
> > > >
> > > > There are some important cookie security features missing in the
> > ancient
> > > > Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping
> support
> > > to
> > > > Servlet 3.0 would allow the Geode AppServer session module to
> > inherently
> > > > support these session cookie security features.
> > > >
> > > > I have logged the following Jira issue:
> > > >
> > > > https://issues.apache.org/jira/browse/GEODE-7438
> > > >
> > > > and submitted a pull request that provides the necessary support if
> the
> > > > Geode community agrees this is a good idea.
> > > >
> > > > And thank you for the excellent Apache Geode project!
> > > >
> > > > --
> > > >
> > > > Charles Smith
> > > >
> > > > Developer/Analyst
> > > >
> > > > Web Architecture and Development
> > > > MacEwan University
> > > > smith...@macewan.ca
> > > >
> > > >
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[John Blum]

Since the Servlet 3.1 spec is available and the current version is 4.0, why
not consider 3.1 or even 4.0, actually?

-j

On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe  wrote:

> Hello Charles; thanks very much for bringing this up.
>
> I vote +1 on this proposal.
>
> Just to add a bit more details for others:
>
> The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
> versions of various containers that supported it are:
>
>- Jetty 8 (EOL'd since 11/2014) [1]
>- Tomcat 7 (Version 6 EOL'd 2017) [2]
>- JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017) [3]
>- Websphere 8.0 (End of support 4/2018) [4]
>- Weblogic 12cR1 (Extended Support until 12/2019) [5]
>
> The implication is that, of these products, there are *no* currently
> supported versions that *do not* support the Servlet 3.0 spec. I believe it
> is quite safe for us to indicate that the Session Modules are now only
> supported on 3.0 compliant containers.
>
> --Jens
>
> [1] -
> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> [2] - http://tomcat.apache.org/whichversion.html
> [3] - https://access.redhat.com/support/policy/updates/jboss_notes
> [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
> [5] -
>
> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
>
> On Fri, Nov 15, 2019 at 8:11 AM Charles Smith  wrote:
>
> > Hello,
> >
> > The Geode HTTP Session Management Module for AppServers currently states:
> > This approach is a generic solution, which is supported by any container
> > that implements the Servlet 2.4 specification.
> > I would like to suggest that this official support be bumped up to the
> > Servlet 3.0 specification.
> >
> > There are some important cookie security features missing in the ancient
> > Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping support
> to
> > Servlet 3.0 would allow the Geode AppServer session module to inherently
> > support these session cookie security features.
> >
> > I have logged the following Jira issue:
> >
> > https://issues.apache.org/jira/browse/GEODE-7438
> >
> > and submitted a pull request that provides the necessary support if the
> > Geode community agrees this is a good idea.
> >
> > And thank you for the excellent Apache Geode project!
> >
> > --
> >
> > Charles Smith
> >
> > Developer/Analyst
> >
> > Web Architecture and Development
> > MacEwan University
> > smith...@macewan.ca
> >
> >
>


-- 
-John
john.blum10101 (skype)

Re: Adding GEODE-7412 to 1.11 release

[John Blum]

+1

On Fri, Nov 8, 2019 at 10:59 AM Patrick Johnson  wrote:

> +1
>
> > On Nov 8, 2019, at 10:56 AM, Udo Kohlmeyer  wrote:
> >
> > Hi there Geode Dev,
> >
> > I would like to request that we add
> https://issues.apache.org/jira/browse/GEODE-7412 <
> https://issues.apache.org/jira/browse/GEODE-7412> to the 1.11 release.
> >
> > This change is a build change that has crept in since 1.8. The issue
> that is to be fixed is that the web archive, (geode-pulse) has since 1.8
> been uploaded as a jar file to maven central.
> >
> > I would like to fix this by having the WAR artifact being pushed to
> maven central again.
> >
> > --Udo
> >
>
>

-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.2.RC1

[John Blum]

+1

Built Spring Data for Apache Geode on 1.9.2 with success.

On Tue, Oct 22, 2019 at 1:28 PM Jinmei Liao  wrote:

> +1
>
> On Tue, Oct 22, 2019 at 11:47 AM Dave Barnes  wrote:
>
> > +1
> > Downloaded, successfully built Geode and Geode-Native docs form source.
> >
> > On Tue, Oct 22, 2019 at 2:17 AM Ju@N  wrote:
> >
> > > +1,
> > >
> > > Downloaded and built from source, created two clusters with multiple
> > > members and verified WAN replication (along with some gateway related
> > > commands) work properly.
> > > Best regards.
> > >
> > >
> > > On Mon, Oct 21, 2019 at 8:04 PM Udo Kohlmeyer  wrote:
> > >
> > > > +1,
> > > >
> > > > Checked that WAR's are generated for geode-web and geode-web-api.
> > > >
> > > > Also ran set of examples and tests from Spring Data Geode (Moore), to
> > > > confirm that it has not broken functionality.
> > > >
> > > > --Udo
> > > >
> > > > On 10/21/19 8:20 AM, Jens Deppe wrote:
> > > > > Since the deadline has expired without enough votes, I am going to
> > > extend
> > > > > it for another 48(ish) hours until 8am PST, Wednesday , 23rd
> October.
> > > > >
> > > > > Thanks
> > > > > --Jens
> > > > >
> > > > > On Tue, Oct 15, 2019 at 10:47 AM Jens Deppe 
> > > > wrote:
> > > > >
> > > > >> Hello Geode Dev Community,
> > > > >>
> > > > >> This is a release candidate for Apache Geode version 1.9.2.RC1.
> > > > >> Thanks to all the community members for their contributions to
> this
> > > > >> release!
> > > > >>
> > > > >> Please do a review and give your feedback, including the checks
> you
> > > > >> performed.
> > > > >>
> > > > >> Voting deadline:
> > > > >> 3PM PST Sun, October 20 2019.
> > > > >>
> > > > >> Please note that we are voting upon the source tag:
> > > > >> rel/v1.9.2.RC1
> > > > >>
> > > > >> Release notes:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
> > > > >>
> > > > >> Source and binary distributions:
> > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
> > > > >>
> > > > >> Maven staging repo:
> > > > >>
> > > https://repository.apache.org/content/repositories/orgapachegeode-1060
> > > > >>
> > > > >> GitHub:
> > > > >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> > > > >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> > > > >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
> > > > >>
> > > > >> Pipelines:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
> > > > >>
> > > > >> Geode's KEYS file containing PGP keys we use to sign the release:
> > > > >> https://github.com/apache/geode/blob/develop/KEYS
> > > > >>
> > > > >> Command to run geode-examples:
> > > > >> ./gradlew -PgeodeReleaseUrl=
> > > > >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> > > > >> -PgeodeRepositoryUrl=
> > > > >>
> > > https://repository.apache.org/content/repositories/orgapachegeode-1060
> > > > >> build runAll
> > > > >>
> > > > >> Regards
> > > > >> --Jens
> > > > >>
> > > >
> > >
> > >
> > > --
> > > Ju@N
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] log4j errors/warnings

[John Blum]

There are other ways of controlling the Log4j2 Status Logger other than
adding test dependencies.


For instance, you can:

1. Set the JVM System property
org.apache.logging.log4j.simplelog.StatusLogger.level to "OFF".

2. Theoretically, when Lo4j2 finds a log4j2 or log4j2-test Properties,
YAML, JSON or XML file on the classpath, it should honor the following
configuration setting, e.g. in log4j2.xml:



This is described in the Log4j documentation at
https://logging.apache.org/log4j/2.x/manual/configuration.html in
section "*Status
Messages*".

Also see the section "*Automatic Configuration*" for more details on how
Log4j2 resolves configuration metadata (e.g. log4j2.xml).

3. There are also programmatical ways to control status logging by
acquiring the StatusLogger and removing all StatusListeners prior to the
Log4j2 logging system being initialized, or alternatively setting a no-op
StatusListener implementation, which you would need to implement yourself
since, seemingly, *Log4j2* does not provide an implementation unlike
*Logback*. (e.g. [1])

StatusLogger.getLogger().getListeners().forEach(StatusLogger.getLogger
()::removeListener);


Quickly experimenting, the only approach I got working in my *Spring Boot*
application using Apache Geode was #1.  I suspect there was other things
running interference, but I did not investigate further.

Anyway, I would error on the side of caution and use 1 of the approaches
above rather than simply throwing in another dependency, testRuntime or
otherwise.  It is too easy for that to be inadvertently and incorrectly
changed by some maintainer later on.

$0.02

-j


[1]
https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-docs/src/main/resources/logback.xml#L4


On Tue, Oct 22, 2019 at 9:57 AM Xiaojian Zhou  wrote:

> I hit this problem in PR. I am just curious why it did not happen before?
>
>
> On Tue, Oct 22, 2019 at 9:44 AM Kirk Lund  wrote:
>
> > I'm ok with adding log4j-core to the testRuntime for all unit test
> targets
> > to prevent the ERROR message. Any other input?
> >
> > On Fri, Oct 18, 2019 at 3:10 PM John Blum  wrote:
> >
> > > Be careful to only add logging dependencies as testRuntime
> dependencies.
> > > Do not add any logger implementation/provider (e.g. log4j-core, or
> > > otherwise) in either the compile-time or runtime scope.
> > >
> > > This also means that when users are using and running Apache Geode
> > > applications (regardless of context), they will need to explicitly
> choose
> > > and declare a logging implementation, otherwise they will see the same
> > > ERROR message logged.  For example, when using Spring Boot, users
> > > would declare a runtime dependency on
> > > org.springframework.boot:spring-boot-starter-logging.  This uses
> Logback
> > as
> > > the logging provider and adapts Log4j with SLF4J using the bridge.
> > >
> > > To make matters worse, unfortunately, this message is logged by the
> > logging
> > > facade as an error when it should rather be logged as WARN instead, or
> > > arguably less.
> > >
> > > Technically, you should also be able to quiet down the "internal"
> Logging
> > > facade messaging using a no-op status listener, e.g. ...
> > >
> > >
> > >
> >
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-tests/smoke-tests/spring-initializer/src/test/resources/logback.xml#L4
> > >
> > > I not sure what that is for Log4j2 (but there should be an equivalent).
> > >
> > >
> > >
> > > On Fri, Oct 18, 2019 at 1:26 PM Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > > wrote:
> > >
> > > > Not long ago changes were made to the sub-projects that introduced a
> > lot
> > > > of build noise.  In gradle builds we see a lot of this:
> > > >
> > > > ERROR StatusLogger Log4j2 could not find a logging implementation.
> > Please
> > > > add log4j-core to the classpath. Using SimpleLogger to log to the
> > > console...
> > > >
> > > > and in IntelliJ unit test runs we get this:
> > > >
> > > > ERROR StatusLogger No Log4j 2 configuration file found. Using default
> > > > configuration (logging only errors to the console), or user
> > > > programmatically provided configurations. Set system property
> > > > 'log4j2.debug' to show Log4j 2 internal initialization logging.
> > > Seehttps://
> > > > logging.apache.org/log4j/2.x/manual/configuration.html  for
> > instructions
> > > > on how to configure Log4j 2
> > > >
> > > > That's really annoying and it looks like Geode is broken.  To fix
> this
> > > > it was suggested that "we would have to add log4j-core to the
> classpath
> > > > of unit tests to get log4j-api to stop complaining".
> > > >
> > > > I think this should be done.  Any objections?
> > > >
> > > >
> > > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> > >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] log4j errors/warnings

[John Blum]

Be careful to only add logging dependencies as testRuntime dependencies.
Do not add any logger implementation/provider (e.g. log4j-core, or
otherwise) in either the compile-time or runtime scope.

This also means that when users are using and running Apache Geode
applications (regardless of context), they will need to explicitly choose
and declare a logging implementation, otherwise they will see the same
ERROR message logged.  For example, when using Spring Boot, users
would declare a runtime dependency on
org.springframework.boot:spring-boot-starter-logging.  This uses Logback as
the logging provider and adapts Log4j with SLF4J using the bridge.

To make matters worse, unfortunately, this message is logged by the logging
facade as an error when it should rather be logged as WARN instead, or
arguably less.

Technically, you should also be able to quiet down the "internal" Logging
facade messaging using a no-op status listener, e.g. ...

https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-tests/smoke-tests/spring-initializer/src/test/resources/logback.xml#L4

I not sure what that is for Log4j2 (but there should be an equivalent).



On Fri, Oct 18, 2019 at 1:26 PM Bruce Schuchardt 
wrote:

> Not long ago changes were made to the sub-projects that introduced a lot
> of build noise.  In gradle builds we see a lot of this:
>
> ERROR StatusLogger Log4j2 could not find a logging implementation. Please
> add log4j-core to the classpath. Using SimpleLogger to log to the console...
>
> and in IntelliJ unit test runs we get this:
>
> ERROR StatusLogger No Log4j 2 configuration file found. Using default
> configuration (logging only errors to the console), or user
> programmatically provided configurations. Set system property
> 'log4j2.debug' to show Log4j 2 internal initialization logging. Seehttps://
> logging.apache.org/log4j/2.x/manual/configuration.html  for instructions
> on how to configure Log4j 2
>
> That's really annoying and it looks like Geode is broken.  To fix this
> it was suggested that "we would have to add log4j-core to the classpath
> of unit tests to get log4j-api to stop complaining".
>
> I think this should be done.  Any objections?
>
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

[John Blum]

+1

On Mon, Oct 14, 2019 at 11:19 AM Udo Kohlmeyer  wrote:

> +1 to including both.
>
> On 10/14/19 10:52 AM, Dick Cavender wrote:
> > +1 for both fixes and the original list
> >
> >
> > On Mon, Oct 7, 2019 at 5:00 PM Owen Nichols  wrote:
> >
> >> Sounds like a big win for convenience, and clearly a regression relative
> >> to the last release of Geode that SBDG picked up (1.6).  Thanks for
> >> clarifying what is at stake.
> >>
> >> +1 for including both fixes
> >>
> >>> On Oct 7, 2019, at 4:50 PM, Udo Kohlmeyer  wrote:
> >>>
> >>> Hi there Owen,
> >>>
> >>> I apologize if it is not clear.
> >>>
> >>> GEODE-7241 is a regression where the published artifact "geode-web" and
> >> "geode-web-api" were published as jars and not wars.
> >>> NOW, why is it critical for 1.9.x... Well, the answer is fairly short.
> >> In Spring Data Geode, there is an ability to start/bootstrap a server
> using
> >> Spring Data Geode(SDG) only. This feature can be used for testing as
> well
> >> as starting a Server using SDG. In order to start the server using SDG,
> all
> >> that is required is to add the geode-web + geode-web-api artifacts onto
> the
> >> classpath as a maven/gradle dependency. There is no more requirement to
> >> download the project and reference libs or using GFSH to start the
> server.
> >>> WHEN the extension went from war -> jar, this functionality was broken.
> >> The latest version of SDG (2.2.x) will be based on Geode 1.9. and not
> 1.10+
> >> which means that SDG will not gain that functionality. SDG would have to
> >> wait for its next release 2.3.x, which is still quite some way off.
> >>> Usually this is not a big thing, but given Spring's prescribed manner
> of
> >> handling versions of dependent libraries, the version of Geode cannot be
> >> changed and only patch versions are allowed. So, in order to address the
> >> regression, a patch to 1.9.x is requested.
> >>> Hope that this explains it a little better.
> >>>
> >>> --Udo
> >>>
> >>> On 10/7/19 3:50 PM, Owen Nichols wrote:
>  I don’t yet have a clear understanding of what makes these critical,
>  especially GEODE-7241. Can you elaborate, including:
>  * Are these fixes already in 1.10?  If not, would a 1.10.1 patch be
>  required as well?
>  * What is the impact of not including each of these fixes?  Is there a
>  workaround?
> 
>  On Fri, Oct 4, 2019 at 10:44 AM Jens Deppe  wrote:
> 
> > I'd like to propose adding these two fixes to release/1.9.2
> >
> > GEODE-7261 ensures that the Admin REST service can start when Spring
> >> Boot
> > Data Geode is used to launch a server.
> >
> > GEODE-7241 publishes our various war artifacts to maven. This ensures
> >> that,
> > in the context of starting a SBDG server, the necessary REST wars can
> >> be
> > made available in order to start the required REST services.
> >
> > Thanks
> >
> > --Jens
> >
> >>
>


-- 
-John
john.blum10101 (skype)

Re: Token based authentication support added in Geode Develop

[John Blum]

got it

On Mon, Oct 7, 2019 at 10:33 AM Joris Melchior  wrote:

> Yes, at the moment the we only support receiving a token provided in the
> Authentication header field. We don't provide the standard endpoints for
> token acquisition and refresh.
>
> On Fri, Oct 4, 2019 at 4:14 PM John Blum  wrote:
>
> > So application developer's will need to know to code their application
> > client's to lookup the JWT token (from some store) and set HTTP request
> > headers to send the token, or will this be handled automatically by a
> geode
> > client?
> >
> > On Fri, Oct 4, 2019 at 11:37 AM Jinmei Liao  wrote:
> >
> > > yes, correct,  we are assuming the client will have the token available
> > > somehow and send in the token in the authentication header. We are not
> > > doing anything with actual token management.
> > >
> > > On Fri, Oct 4, 2019 at 11:34 AM Jens Deppe  wrote:
> > >
> > > > So, to be clear, we're providing the ability to recognize a HTTP
> > > > authentication header containing 'Bearer '
> > and
> > > > then handing that to the Security Manager to do with as it pleases?
> > > >
> > > > We're not doing anything with actual token management? (i.e.
> > generating,
> > > > revoking, etc.).
> > > >
> > > > --Jens
> > > >
> > > > On Fri, Oct 4, 2019 at 10:59 AM Jinmei Liao 
> wrote:
> > > >
> > > > > Hi, all
> > > > >
> > > > > JWT token based authentication support is added to Geode develop
> > > branch.
> > > > > Currently only management v2 rest api can use this (we can add dev
> > rest
> > > > > there too if requested). In order to turn on token based auth for
> > > > > management rest api, you will need to do these two things:
> > > > > 1. start your locator with this property:
> > > > >  *security-auth-token-enabled-components = all (or management)*
> > > > > 2. implement your SecurityManager to authenticate the jwt token
> > passed
> > > > in.
> > > > > The jwt token will be available in the properties using the key
> > > > > "security-token".
> > > > >
> > > > > Let me know if you have any questions.
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> <https://en.wikipedia.org/wiki/Hal_Abelson>
>


-- 
-John
john.blum10101 (skype)

Re: Token based authentication support added in Geode Develop

[John Blum]

So application developer's will need to know to code their application
client's to lookup the JWT token (from some store) and set HTTP request
headers to send the token, or will this be handled automatically by a geode
client?

On Fri, Oct 4, 2019 at 11:37 AM Jinmei Liao  wrote:

> yes, correct,  we are assuming the client will have the token available
> somehow and send in the token in the authentication header. We are not
> doing anything with actual token management.
>
> On Fri, Oct 4, 2019 at 11:34 AM Jens Deppe  wrote:
>
> > So, to be clear, we're providing the ability to recognize a HTTP
> > authentication header containing 'Bearer ' and
> > then handing that to the Security Manager to do with as it pleases?
> >
> > We're not doing anything with actual token management? (i.e. generating,
> > revoking, etc.).
> >
> > --Jens
> >
> > On Fri, Oct 4, 2019 at 10:59 AM Jinmei Liao  wrote:
> >
> > > Hi, all
> > >
> > > JWT token based authentication support is added to Geode develop
> branch.
> > > Currently only management v2 rest api can use this (we can add dev rest
> > > there too if requested). In order to turn on token based auth for
> > > management rest api, you will need to do these two things:
> > > 1. start your locator with this property:
> > >  *security-auth-token-enabled-components = all (or management)*
> > > 2. implement your SecurityManager to authenticate the jwt token passed
> > in.
> > > The jwt token will be available in the properties using the key
> > > "security-token".
> > >
> > > Let me know if you have any questions.
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Support For LTS Version Of Geode

[John Blum]

1 more thing...

I am also not saying all Apache Geode LTS versions (e.g. 1.9) need to
perfectly align with the SD Release Train for which the SD Release Train is
based (e.g. SD Moore/2.2 <-> 1.9), release by release, especially given we
have quite a few service/patch releases per SD Release Train (e.g. SD
Lovelace is already at SR10/2.1.10.RELEASE or 10 service/patch releases
beyond the 2.1 GA version, i.e. 2.1.0.RELEASE).  Just that, enhancements,
important bug fixes, and CVEs (patches) are back ported to an LTS version
of Apache Geode from time to time up to, say, 1 year (or 3 or 4 patches).

This may have the effect that Apache Geode users might not upgrade until a
new LTS version becomes available.  However, for those that want to stay
ion the cutting edge, they are free to do so.  It also allows the Apache
Geode product to take more risk between LTS versions and really stabilize
for an LTS version.

To Owen's point, I am also wondering why it is so important that users
always pick up the latest bits?  I think this is much more problematic to
do on the server-side, plus newer clients cannot talk to older servers,
so...

And, of course, there is no reason why Apache Geode needs to do any of what
I am suggesting just for the Spring Data bits.  But, it would make our
lives simpler overall, which is why I am advocating for it.

Final $0.02,

-j



On Mon, Sep 30, 2019 at 6:13 PM John Blum  wrote:

> Well, release durations are subjective to begin with.  What makes a 3
> month cycle any better than a 6 month cycle or vice versa?
>
> For one, I think it is very project dependent.  Rather, SD strives to
> achieve a predictable release cycle (i.e. fixed duration over X amount of
> scope, e.g. every 6 months, from M1 to final GA where we might have any
> number of Milestones and Release Candidates between M1 and final GA).
> Also, there is a commitment to our customers, so the 1 year cycle is not
> arbitrary.
>
> The entire SD Release Train also encompass 14 different modules
> (GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot
> more moving parts to coordinate with different intended feature sets per
> module (some of it aligning with SD Commons while other bits are very store
> specific) over the course of arriving at the final GA.
>
> Finally, I'd say that what is the point of having a patch version (i.e. in
> major.minor.patch) if the only intent to use is to fix CVEs.  You could
> simply force users to the new minor version containing the fixes.
>
> However, I am very much in favor having patch releases, particularly for
> data products where upgrading is not a trivial task, and not simply a
> technical one, either.
>
> Again, $0.02,
>
> -John
>
>
> On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz  wrote:
>
>> I agree.
>>
>> This is the most sensible way to achieve release alignment.
>>
>>
>> --
>> Mike Stolz
>> Principal Engineer, Pivotal Cloud Cache
>> Mobile: +1-631-835-4771
>>
>> On Mon, Sep 30, 2019, 8:09 PM John Blum  wrote:
>>
>> > Put simply, from my perspective, I would like to see LTS versions of
>> Apache
>> > Geode align with the *Spring Data* (*Release Trains*) support for Apache
>> > Geode.
>> >
>> > For example:
>> >
>> > SDG Lovelace/2.1 is based on Apache Geode 1.6.x.
>> > SDG Moore/2.2 is based on Apache Geode 1.9.x.
>> >
>> > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with
>> patch
>> > releases.
>> >
>> > The upcoming SD Neuman/2.3 (now in development given Moore has just
>> went GA
>> > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is
>> > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13)
>> before
>> > SD Neuman reaches RC1.
>> >
>> > SD has longer lifecycles between release trains (1 to 1.5 years per SD
>> > Release Train) than Apache Geode's support cycle, on a particular
>> > major.minor version (e.g. 1.9), which always puts us in a
>> > precarious position.
>> >
>> > $0.02
>> > -John
>> >
>> >
>> >
>> > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl  wrote:
>> >
>> > > Hi All,
>> > >
>> > > It has come up a few times in recent weeks about the possibility of an
>> > LTS
>> > > version of Geode. Is this something the community would be interested
>> in?
>> > >
>> > > There are advantages and disadvantages to supporting an LTS. Some
>> > > advantages may include:
>> > > - Stable release for downstream projects
>> > > - Include security and other maintenance related patches
>> > >
>> > > Disadvantages:
>> > > - Additional support for multiple distributions/versions
>> > > - Release management overhead
>> > >
>> > > Thoughts/Comments/Concerns?
>> > >
>> > > --Mark
>> > >
>> >
>> >
>> > --
>> > -John
>> > john.blum10101 (skype)
>> >
>>
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Support For LTS Version Of Geode

[John Blum]

Well, release durations are subjective to begin with.  What makes a 3 month
cycle any better than a 6 month cycle or vice versa?

For one, I think it is very project dependent.  Rather, SD strives to
achieve a predictable release cycle (i.e. fixed duration over X amount of
scope, e.g. every 6 months, from M1 to final GA where we might have any
number of Milestones and Release Candidates between M1 and final GA).
Also, there is a commitment to our customers, so the 1 year cycle is not
arbitrary.

The entire SD Release Train also encompass 14 different modules
(GemFire/Geode, JPA, MongoDB, Redis, Cassandra, etc) so there are a lot
more moving parts to coordinate with different intended feature sets per
module (some of it aligning with SD Commons while other bits are very store
specific) over the course of arriving at the final GA.

Finally, I'd say that what is the point of having a patch version (i.e. in
major.minor.patch) if the only intent to use is to fix CVEs.  You could
simply force users to the new minor version containing the fixes.

However, I am very much in favor having patch releases, particularly for
data products where upgrading is not a trivial task, and not simply a
technical one, either.

Again, $0.02,

-John


On Mon, Sep 30, 2019 at 5:48 PM Michael Stolz  wrote:

> I agree.
>
> This is the most sensible way to achieve release alignment.
>
>
> --
> Mike Stolz
> Principal Engineer, Pivotal Cloud Cache
> Mobile: +1-631-835-4771
>
> On Mon, Sep 30, 2019, 8:09 PM John Blum  wrote:
>
> > Put simply, from my perspective, I would like to see LTS versions of
> Apache
> > Geode align with the *Spring Data* (*Release Trains*) support for Apache
> > Geode.
> >
> > For example:
> >
> > SDG Lovelace/2.1 is based on Apache Geode 1.6.x.
> > SDG Moore/2.2 is based on Apache Geode 1.9.x.
> >
> > Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with
> patch
> > releases.
> >
> > The upcoming SD Neuman/2.3 (now in development given Moore has just went
> GA
> > (i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is
> > likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13)
> before
> > SD Neuman reaches RC1.
> >
> > SD has longer lifecycles between release trains (1 to 1.5 years per SD
> > Release Train) than Apache Geode's support cycle, on a particular
> > major.minor version (e.g. 1.9), which always puts us in a
> > precarious position.
> >
> > $0.02
> > -John
> >
> >
> >
> > On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl  wrote:
> >
> > > Hi All,
> > >
> > > It has come up a few times in recent weeks about the possibility of an
> > LTS
> > > version of Geode. Is this something the community would be interested
> in?
> > >
> > > There are advantages and disadvantages to supporting an LTS. Some
> > > advantages may include:
> > > - Stable release for downstream projects
> > > - Include security and other maintenance related patches
> > >
> > > Disadvantages:
> > > - Additional support for multiple distributions/versions
> > > - Release management overhead
> > >
> > > Thoughts/Comments/Concerns?
> > >
> > > --Mark
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Support For LTS Version Of Geode

[John Blum]

Put simply, from my perspective, I would like to see LTS versions of Apache
Geode align with the *Spring Data* (*Release Trains*) support for Apache
Geode.

For example:

SDG Lovelace/2.1 is based on Apache Geode 1.6.x.
SDG Moore/2.2 is based on Apache Geode 1.9.x.

Therefore, both Apache Geode 1.6 and 1.9 would be LTS versions, with patch
releases.

The upcoming SD Neuman/2.3 (now in development given Moore has just went GA
(i.e. 2.2.0.RELEASE) as of today), is currently based on 1.10, but is
likely to move Apache Geode versions (e.g. 1.11, 1.12, or even 1.13) before
SD Neuman reaches RC1.

SD has longer lifecycles between release trains (1 to 1.5 years per SD
Release Train) than Apache Geode's support cycle, on a particular
major.minor version (e.g. 1.9), which always puts us in a
precarious position.

$0.02
-John



On Mon, Sep 30, 2019 at 3:55 PM Mark Bretl  wrote:

> Hi All,
>
> It has come up a few times in recent weeks about the possibility of an LTS
> version of Geode. Is this something the community would be interested in?
>
> There are advantages and disadvantages to supporting an LTS. Some
> advantages may include:
> - Stable release for downstream projects
> - Include security and other maintenance related patches
>
> Disadvantages:
> - Additional support for multiple distributions/versions
> - Release management overhead
>
> Thoughts/Comments/Concerns?
>
> --Mark
>


-- 
-John
john.blum10101 (skype)

Re: [ANNOUNCE] Apache Geode 1.10.0

[John Blum]

Congrats!!!  Nice work!

On Thu, Sep 26, 2019 at 2:08 PM Dick Cavender  wrote:

> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.10.0.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> This Geode 1.10.0 quarterly release contains a number of improvements and bug 
> fixes.
>
> Users are encouraged to upgrade to the latest release.
>
> For the full list of changes please review the release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.10.0
>
>
> The release artifacts can be downloaded from the project 
> website:http://geode.apache.org/releases/
>
> The release documentation is available at:
>
> https://geode.apache.org/docs/guide/110/about_geode.html
>
>
> We would like to thank all the contributors that made the release possible.
>
> Regards,
>
> Dick Cavender on behalf of the Apache Geode team
>
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Geode 1.11.0 dependency update

[John Blum]

Hi Dick-

Thanks for the reminder on an important topic.

On quick review of *Nick's* proposal, which I like (well done), I would
only add that if a patch release is cut (e.g. 1.9.1, 1.9.2) that
dependencies be reviewed for updated patch releases as well.

While different patch versions of dependency major.minor version SHOULD NOT
cause issues, it is also a nice thing to do since critical bugs, or CVEs,
may be resolved in a patch release of a dependency.

Cheers,
John


On Thu, Sep 26, 2019 at 2:59 PM Jacob Barrett  wrote:

> Yes please!
>
> > On Sep 26, 2019, at 2:46 PM, Dick Cavender  wrote:
> >
> > With the release of Geode 1.10.0 the window opens to apply Nick's Geode
> > dependency update process with time to shake it out before the 1.11.0
> > release.
> >
> > His proposal can be found here:
> >
> https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+Geode+dependency+update+process
> >
> >
> > Additionally the original email discuss thread can be found searching for
> > subject: "[DISCUSS] Geode dependency update process (review by
> 8/28/2019)"
> >
> > His proposal suggests that the dependency update task be something that
> the
> > Geode Release Manager would do post release. While it may be that a RM
> can
> > eventually do this until the actual update process, verification and
> > documenting is defined it seems like this should be a geode community
> > effort the first time around.
> >
> > Nick has generously offered to head up the initial process and to use the
> > Geode 1.10.0 release as an opportunity to kickoff his proposal. Thanks
> Nick!
>
>

-- 
-John
john.blum10101 (skype)

Re: Spring Boot with Geode 1.10

[John Blum]

Additionally, I would encourage others to read...

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-maven-plugin

And, when using Gradle (instead)...

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-gradle-plugin

This section of Spring Boot's Maven/Gradle Plugin explains it best...

https://docs.spring.io/spring-boot/docs/2.1.7.RELEASE/gradle-plugin/reference/html/#managing-dependencies

-j


On Wed, Sep 25, 2019 at 1:24 PM John Blum  wrote:

> There is no version of Spring Boot (SBDG) currently built on Apache Geode
> 1.10 at the moment.
>
> In general, you should understand 2 things.
>
>
> 1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent
> on is indirectly (transitively) determined by upstream dependencies.
>
> SBDG -> Spring Boot -> SDG -> Apache Geode.
>
> E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x.  SBDG 1.2 pulls in SDG
> Moore/2.2.  Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and
> Spring Boot must agree on the version of SD[G] that they use.  So, it is
> not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD
> Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9.
>
> E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6.  SBDG 1.1 pulls in SDG
> Lovelace/2.1.  Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2.  Both SBDG
> and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1
> respectively.
>
>
> 2. Next, Spring Boot's dependency management extends beyond simply Spring
> Data, to other (upstream, from Boot) Spring projects/dependencies (e.g.
> Spring Framework, Spring Batch, Spring Integration, Spring Security, etc)
> as well as 3rd party libraries.
>
>
> Any, and I mean ANY (!) properly managed Java project, not just Spring,
> must manage dependencies in a consistent and responsible way to avoid
> conflicts that would cause end users issues (especially with their
> applications that consume our dependencies) given multiple transitive
> dependencies are likely to share the same dependencies (e.g. logging is
> always usually the most common example).
>
> You should not assume you can just simply change dependencies at random
> (e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer
> versions, or whatever).  The stars must align so to speak, and for good
> reason.  Again, this is why tools like Apache Maven exists in the first
> place.
>
> In some cases, this might work, but it is not normal to think you can do
> this in general, and most of the Java community understands this.  It must
> be a conscious choice and users are aware that they must manually
> exclude/override a dependency and/or declare their own dependencyManagement
> section in their application POM to declare their choices.
>
> Anyway, this 1 of the many reasons why Spring Boot so eloquently handles
> this concern for you.
>
> SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches
> GA.  Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot
> 2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies
> at that time.
>
> The fact that Micrometer 1.0.3 was mention would mean that you are using
> `spring-geode-starter` 1.0.x since Spring Boot has not be based on
> Micrometer 1.0.x since 2.0 [3], which is now EOL.
>
> -j
>
> [1]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243
> [2]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153
> [3]
> https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127
>
>
> On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett  wrote:
>
>> Offline discovery…
>>
>> Looking at ./gradlew dependencies shows that micrometer is being
>> downgraded by spring dependency plugin to 1.0.3. Attempting different
>> versions of spring boot.
>>
>> -Jake
>>
>>
>> > On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
>> >
>> > This still pulls in micrometer 1.0.3
>> >
>> > dependencies {
>> >  compile('org.springframework.boot:spring-boot-starter')
>> >
>> >  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
>> >  implementation('org.apache.geode:geode-core')
>> >  implementation('org.apache.geode:geode-cq')
>> >
>> >  testCompile('org.springframework.boot:spring-boot-starter-test')
>> >  testCompile 'junit:junit:4.+'
>> > }
>> >
>> >
&

Re: Spring Boot with Geode 1.10

[John Blum]

There is no version of Spring Boot (SBDG) currently built on Apache Geode
1.10 at the moment.

In general, you should understand 2 things.


1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent
on is indirectly (transitively) determined by upstream dependencies.

SBDG -> Spring Boot -> SDG -> Apache Geode.

E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x.  SBDG 1.2 pulls in SDG
Moore/2.2.  Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and
Spring Boot must agree on the version of SD[G] that they use.  So, it is
not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD
Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9.

E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6.  SBDG 1.1 pulls in SDG
Lovelace/2.1.  Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2.  Both SBDG
and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1
respectively.


2. Next, Spring Boot's dependency management extends beyond simply Spring
Data, to other (upstream, from Boot) Spring projects/dependencies (e.g.
Spring Framework, Spring Batch, Spring Integration, Spring Security, etc)
as well as 3rd party libraries.


Any, and I mean ANY (!) properly managed Java project, not just Spring,
must manage dependencies in a consistent and responsible way to avoid
conflicts that would cause end users issues (especially with their
applications that consume our dependencies) given multiple transitive
dependencies are likely to share the same dependencies (e.g. logging is
always usually the most common example).

You should not assume you can just simply change dependencies at random
(e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer
versions, or whatever).  The stars must align so to speak, and for good
reason.  Again, this is why tools like Apache Maven exists in the first
place.

In some cases, this might work, but it is not normal to think you can do
this in general, and most of the Java community understands this.  It must
be a conscious choice and users are aware that they must manually
exclude/override a dependency and/or declare their own dependencyManagement
section in their application POM to declare their choices.

Anyway, this 1 of the many reasons why Spring Boot so eloquently handles
this concern for you.

SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches
GA.  Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot
2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies
at that time.

The fact that Micrometer 1.0.3 was mention would mean that you are using
`spring-geode-starter` 1.0.x since Spring Boot has not be based on
Micrometer 1.0.x since 2.0 [3], which is now EOL.

-j

[1]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243
[2]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153
[3]
https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127


On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett  wrote:

> Offline discovery…
>
> Looking at ./gradlew dependencies shows that micrometer is being
> downgraded by spring dependency plugin to 1.0.3. Attempting different
> versions of spring boot.
>
> -Jake
>
>
> > On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
> >
> > This still pulls in micrometer 1.0.3
> >
> > dependencies {
> >  compile('org.springframework.boot:spring-boot-starter')
> >
> >  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
> >  implementation('org.apache.geode:geode-core')
> >  implementation('org.apache.geode:geode-cq')
> >
> >  testCompile('org.springframework.boot:spring-boot-starter-test')
> >  testCompile 'junit:junit:4.+'
> > }
> >
> >
> >> On Sep 25, 2019, at 12:43 PM, Jacob Barrett 
> wrote:
> >>
> >> Changing subject…
> >>
> >>
> >> Try
> >> dependencies {
> >>
> implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
> >>  implementation(‘org.apache.geode:geode-core’)
> >>  implementation('org.apache.geode:geode-cq’)
> >> }
> >>
> >> Does that make a difference?
> >>
> >>
> >>> On Sep 25, 2019, at 12:35 PM, Owen Nichols 
> wrote:
> >>>
> >>> My build.gradle is pretty simple:
> >>>
> >>> repositories {
> >>> mavenCentral()
> >>> maven {
> >>>  url '
> https://repository.apache.org/content/repositories/orgapachegeode-1059'
> >>> }
> >>> }
> >>>
> >>> dependencies {
> >>> compile('org.springframework.boot:spring-boot-starter')
> >>> compile 'org.apache.geode:geode-core:1.10.0'
> >>> compile 'org.apache.geode:geode-cq:1.10.0'
> >>> }
> >>>
> >>>
>  On Sep 25, 2019, at 12:29 PM, Jacob Barrett 
> wrote:
> 
> 
> 
> > On Sep 25, 2019, at 12:26 PM, Owen Nichols 
> wrote:
> >
> > ⚠️ to run my spring boot client for above test, I had to manually
> add compile 

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.

On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett  wrote:

> Udo,
>
> I didn’t say we shouldn’t fix it for the future. I said I don’t believe it
> warrants a backport and a patch release.
>
> -Jake
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

It occurred to me after *Charlie* shared the link to installing *Pulse* in
a standalone Servlet Container (e.g. Apache Tomcat) that we don't properly
describe how to handle the Geode dependencies (e.g. geode-core).  Again,
this is not bundled as part of the Geode WAR files.

-1 to publishing a GWAR file.  These are still valid WAR files regardless
of the dependencies they provide or don't provide (which is a documentation
concern in my mind).


On Wed, Sep 25, 2019 at 10:53 AM Anthony Baker  wrote:

> Thanks for the reminder.  If these files are required to start a geode
> member, I agree they should be published artifacts.  Perhaps there’s a
> better way to pull them in…but this seems like the best option for now.
>
> Anthony
>
>
> > On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer 
> wrote:
> >
> > @Anthony. Ticket was updated.. In a nutshell, to run integration tests,
> using the REST endpoints, requires the starting of the server with and
> embedded web-server.
> >
> > As all tests run on dependency management only and don't have access to
> a downloaded product, the HTTP endpoints are not part of the dependency.
> These are added in by including the WAR files from mavenCentral.
> >
> > As @Dan pointed out, GEODE-5660 enabled this behavior.
> >
> > I think this approach might actually even help with the testing of the
> REST Controller in the Geode codebase itself.
> >
> > --Udo
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

Actually, to clarify 2 points.

1. Technically, it is a bit more involved than simply just validating the
"format".  For instance, the web.xml file must be valid and well-formed.
2. There was a reason why the geode-core and other Apache Geode libs were
not bundled in WEB-INF/lib of the WAR files, since then it would create
duplication on the global as well as the WAR file's (isolated) ClassLoader
classpath, particularly for the "embedded" Geode Servlet Container case,
and as such, ClassLoader problems would occur.



On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:

> Udo,
>
> Can you update GEODE-7241 to help us understand the reason why we need to
> publish geode-web* WARs to maven?  I get that we used to do this but I
> can’t recall why we choose that approach.
>
> There is one request for Pulse on maven (GEODE-6208).
>
> Anthony
>
>
> > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> >
> > Maybe the better question is, WHY are we publishing geode-web and
> geode-web-api.
> >
> > Pulse, from what I remember, could be a standalone deployment. At least
> that is what I remember.
> >
> > Most likely an oversight...
> >
> > --Udo
> >
> > On 9/24/19 3:38 PM, Robert Houghton wrote:
> >> The geode-pulse module also builds a war, but does not publish it. Is
> this
> >> an oversight, or by design?
> >>
> >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
> >> wrote:
> >>
> >>> I am working on the change to get the geode-web and geode-web-api war
> >>> artifacts published instead of the jars. I have found the
> >>> geode-web-management project is also producing a war artifact, in
> addition
> >>> to a jar. Do we want it to be published as well? What is the criterion
> we
> >>> use to decide?
> >>>
> >>> I think this problem was an oversight from the changes PurelyApplied
> and I
> >>> made to the build when we made the publish plugin 'opt-in' instead of
> >>> forced by the root project. Easy to publish one or the other, but I am
> not
> >>> qualified to decide whether a war or jar is more appropriate for these
> >>> modules.
> >>>
> >>> Thank you,
> >>> -Robert
> >>>
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

Bundling "all" dependencies in a WAR file is a rather subjective topic
since, typically, in practice developers did not bundle things like JDBC
drivers in a WAR file for their Web app.  Common practice was to put
"shared" libs in the Servlet Containers global libs directory (using the
Common ClassLoader) for shared consumption by all Web apps, for better or
worse.

WAR files (like JAR and EAR) are based on "format" (e.g. containing a
WEB-INF/web.xml file, with WEB-INF/classes of the app and possibly libs in
WEB-INF/lib), not simply just deps. As such, by following this format, the
container will consider this a "valid" WAR file.

However, if we are just basing it on libs, then none of the WAR files are
valid by that definition (not even Pulse) because none contain the
necessary Apache Geode libs (e.g. geode-core).  Therefore, none of the WAR
files could stand on their own, not even Pulse.


On Wed, Sep 25, 2019 at 8:17 AM Udo Kohlmeyer  wrote:

> Seems these should have been Jars all along...
>
> On 9/24/19 8:09 PM, Jacob Barrett wrote:
> > Why publish them as WAR files at all? As they are currently packaged
> they can't be deployed in just any J2EE web container because they lack all
> the dependencies. Sure they look like WAR files internally but they are
> really modules that expect to run in and only in the Geode server.
> Publishing them as a WAR file gives the false impression that they can be
> consumed by any project as a full fledged WAR.
> >
> > We should make up our own JAR spec based on WAR, perhaps calling it
> Geode Web ARchive or GWAR for short. Yes, I just went there… GWAR!!!
> 落落落落
> >
> > But seriously, unless it can be deployed in any J2EE web container it
> shouldn’t be considered a WAR.
> >
> > -Jake
> >
> >> On Sep 24, 2019, at 3:34 PM, Robert Houghton 
> wrote:
> >>
> >> I am working on the change to get the geode-web and geode-web-api war
> >> artifacts published instead of the jars. I have found the
> >> geode-web-management project is also producing a war artifact, in
> addition
> >> to a jar. Do we want it to be published as well? What is the criterion
> we
> >> use to decide?
> >>
> >> I think this problem was an oversight from the changes PurelyApplied
> and I
> >> made to the build when we made the publish plugin 'opt-in' instead of
> >> forced by the root project. Easy to publish one or the other, but I am
> not
> >> qualified to decide whether a war or jar is more appropriate for these
> >> modules.
> >>
> >> Thank you,
> >> -Robert
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] - Cutting of release 1.9.2

[John Blum]

+1 for releasing Apache Geode 1.9.2 and including the fix for GEDOE-7121.

On Fri, Sep 20, 2019 at 1:11 PM Kirk Lund  wrote:

> +1 for creating 1.9.x with the fix for GEODE-7121
>
>
> On Fri, Sep 20, 2019 at 1:09 PM John Blum  wrote:
>
> > Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is
> > tentatively scheduled for Monday, Sept. 30th.
> >
> > On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:
> >
> > > Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG
> > 2.2.0?
> > >
> > > On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:
> > >
> > > > Hi there Geode Dev's,
> > > >
> > > > I would like to propose a release for Geode 1.9.x that includes
> > > > https://issues.apache.org/jira/browse/GEODE-7121.
> > > >
> > > > This is an issue that is current in the 1.9.x branch, which is used
> by
> > > > Spring Data Geode 2.1.10 <
> https://spring.io/projects/spring-data-geode
> > >.
> > > >
> > > > This issue can cause an application using Spring Data Geode to
> > bootstrap
> > > > GEODE to deadlock upon start up.
> > > >
> > > > This is critical system's issue and given that Spring Data Geode
> cannot
> > > > change its underlying dependency to 1.10+, would require this fix to
> be
> > > > back-ported to the 1.9 branch.
> > > >
> > > > --Udo
> > > >
> > > >
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] - Cutting of release 1.9.2

[John Blum]

Correction to *Udo's* comments!

SDG Moore/2.2 is based on Apache Geode 1.9, NOT SDG Lovelace/2.1 (which is
based on Apache Geode 1.6).

You can review the version compatibility matrix beginning with SBDG, here (
https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix
).

On Fri, Sep 20, 2019 at 1:09 PM John Blum  wrote:

> Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is
> tentatively scheduled for Monday, Sept. 30th.
>
> On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:
>
>> Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG 2.2.0?
>>
>> On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:
>>
>> > Hi there Geode Dev's,
>> >
>> > I would like to propose a release for Geode 1.9.x that includes
>> > https://issues.apache.org/jira/browse/GEODE-7121.
>> >
>> > This is an issue that is current in the 1.9.x branch, which is used by
>> > Spring Data Geode 2.1.10 <https://spring.io/projects/spring-data-geode
>> >.
>> >
>> > This issue can cause an application using Spring Data Geode to bootstrap
>> > GEODE to deadlock upon start up.
>> >
>> > This is critical system's issue and given that Spring Data Geode cannot
>> > change its underlying dependency to 1.10+, would require this fix to be
>> > back-ported to the 1.9 branch.
>> >
>> > --Udo
>> >
>> >
>>
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] - Cutting of release 1.9.2

[John Blum]

Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is
tentatively scheduled for Monday, Sept. 30th.

On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:

> Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG 2.2.0?
>
> On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:
>
> > Hi there Geode Dev's,
> >
> > I would like to propose a release for Geode 1.9.x that includes
> > https://issues.apache.org/jira/browse/GEODE-7121.
> >
> > This is an issue that is current in the 1.9.x branch, which is used by
> > Spring Data Geode 2.1.10 .
> >
> > This issue can cause an application using Spring Data Geode to bootstrap
> > GEODE to deadlock upon start up.
> >
> > This is critical system's issue and given that Spring Data Geode cannot
> > change its underlying dependency to 1.10+, would require this fix to be
> > back-ported to the 1.9 branch.
> >
> > --Udo
> >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

+1 to Bruce's comments as well.

This is exactly the kind of thing I needed to do (handle) inside of the *Spring
Test for Apache Geode* (STDG) project from a framework perspective, to
ensure that other projects relying on STDG (e.g. SBDG, SSDG) for their
integration testing purposes (e.g. client/server integration test cases)
with Apache Geode, were reliable, in an automated fashion.  This meant
ensuring things like the Apache Geode process is completely and properly
shutdown (using the appropriate checks) all all resource used by a cache
instance are released before another test class is allowed to continue and
do its work.  FWIW.

-j

On Wed, Sep 11, 2019 at 10:28 AM Mark Hanson  wrote:

> The idea I am working with at the moment that Kirk pointed me at was to
> use the pid file in the directory as indicator. Once that file disappears
> the server is stopped.
>
> That seems to work in my testing.
>
> Thoughts?
>
> Thanks,
> Mark
>
> > On Sep 11, 2019, at 10:23 AM, Dan Smith  wrote:
> >
> > It does seem like we should make stop synchronous, or at least make start
> > wait for the old process to die as Bruce suggested. Otherwise it is
> > difficult for someone to script the restart of a server.
> >
> > Looking at the code, it does look like gfsh stop is asynchronous. There
> are
> > multiple ways to stop a server:
> > * gfsh stop --dir - it looks like we write out some stop file and return
> > immediately. Or, if we can connect over JMX, we invoke the
> > MemberMBean.shutDownMember method, which launches a thread to close the
> > cache, which is also asynchronous.
> > * gfsh stop --pid - this seems to be similar to --dir
> > * With a member name - this appears to go to the
> MemberMBean.shutDownMember
> > method as well.
> >
> > I think one issue is that the JMX methods to stopping the server may be
> > hard to ensure the process is really gone, because they can be invoked
> > remotely. That may be why they are asynchronous - they need to return
> > something to the caller before shutting down. So maybe Bruce's suggestion
> > is better.
> >
> > As Jens pointed out - tests should generally just use port 0 for servers.
> >
> > -Dan
> >
> > On Wed, Sep 11, 2019 at 8:46 AM Jens Deppe  wrote:
> >
> >> To circle back to the original test failure that prompted this
> discussion -
> >> the failing test was getting intermittent bind exceptions on subsequent
> >> server restarts.
> >>
> >> I believe it's quite likely that a process' ports will remain
> unavailable
> >> even after it is gone (I'm not sure if we create listening sockets with
> >> SO_REUSEADDR). So, as to John's comment that gfsh is already
> synchronous, I
> >> don't think that adding extra functionality to gfsh, to ultimately just
> >> wait longer before exiting, is really solving the problem. I'd suggest
> you
> >> adjust the tests to always start servers with `--server-port=0` so that
> >> there are no port conflicts and let the OS handle it.
> >>
> >> --Jens
> >>
> >> On Wed, Sep 11, 2019 at 8:17 AM Bruce Schuchardt <
> bschucha...@pivotal.io>
> >> wrote:
> >>
> >>> Blocking or non-blocking, I don't have a strong opinion.  What I'd
> >>> really like to have gfsh ensure, though, is that no-one is able to
> start
> >>> a new instance of a server while the old process is still around.
> Maybe
> >>> the PID file is the way to do that.
> >>>
> >>> On 9/10/19 3:08 PM, Mark Hanson wrote:
>  Hello All,
> 
>  I would like to propose that we make the gfsh “stop server” command
> >>> synchronous. It is causing some issues with some tests as the rest of
> the
> >>> calls are blocking. Stop on the other hand immediately returns by
> >>> comparison.
>  This causes issues as shown in GEODE-7017 specifically.
> 
>  GEODE:7017 CI failure:
> >>> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> >>> startupReportsOnlineOnlyAfterRedundancyRestored
>  https://issues.apache.org/jira/browse/GEODE-7017 <
> >>> https://issues.apache.org/jira/browse/GEODE-7017>
> 
> 
>  What do people think?
> 
>  Thanks,
>  Mark
> >>>
> >>
>
>

-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

@Mike - Who said anything about...

"*masking it in an early return from the shutdown command doesn't seem like
the appropriate action.*"

I think you missed the point.  You explicitly have to break out of the
wait, which is a conscious decision when *Gfsh* is run interactively.

The command as I previously stated, is "blocking", or "synchronous" with
respect to cache.close(), which is "ultimately" what gets called whether
the stop happens in-process or out-of-process (for that matter).  So, in a
non-interactive mode, the real issue is, why is the cache not completely
and properly closed/shutdown after a cache.close() call then?

Fix cache.close() then!  Don't simply bandaid this thing with yet another
unreliable means to ascertain whether the cache was completely and properly
shutdown.  And, don't put responsibility on the user to have register and
receive notification on complete shutdown, or some other ridiculous means,
either.


On Tue, Sep 10, 2019 at 6:15 PM Michael Stolz  wrote:

> I understand that issue John, but masking it in an early return from the
> shutdown command doesn't seem like the appropriate action.
> Maybe we should consider that nearly all gfsh commands are not blocking,
> and rather, have a way to determine which ones are still waiting for
> completion?
>
> --
> Mike Stolz
> Principal Engineer, Pivotal Cloud Cache
> Mobile: +1-631-835-4771
>
>
>
> On Tue, Sep 10, 2019 at 9:13 PM John Blum  wrote:
>
> > @Anil-  I hear your argument when you are "scripting" with *Gfsh*, but
> > blocking absolutely maybe less desirable when using *Gfsh* interactively.
> > There are, after all, many non-cluster based commands.
> >
> > @Mark - I see.  I have generally found in my own testing purposes,
> > especially automated, that a cache instance is not fully closed and has
> not
> > properly released all it's resource even after cache.close() returns.
> >
> > -j
> >
> > On Tue, Sep 10, 2019 at 5:02 PM Mark Hanson  wrote:
> >
> > > Hi John,
> > >
> > > Kirk and I found that in our testing it was returning before it was
> fully
> > > stopped. I have a change that seems viable that waits for the pid file
> to
> > > disappear from the subdirectory of the server. I am not a fan. I would
> > > prefer to wait for the pid to disappear, but that doesn’t seem like it
> > will
> > > be cross-platform friendly.
> > >
> > > Thanks,
> > > Mark
> > >
> > > > On Sep 10, 2019, at 3:31 PM, John Blum  wrote:
> > > >
> > > > `stop server` is synchronous (with an option to break out of the wait
> > > using
> > > > CTRL^C) AFAIR.
> > > >
> > > > Way deep down inside, it simply relies on GemFireCache.close() to
> > return
> > > > (in-process).
> > > >
> > > > As Darrel mentioned, there is not "true" signal the the server was
> > > > successfully stopped.
> > > >
> > > > -j
> > > >
> > > >
> > > > On Tue, Sep 10, 2019 at 3:23 PM Darrel Schneider <
> > dschnei...@pivotal.io>
> > > > wrote:
> > > >
> > > >> I think it would be good for stop server to confirm in some way that
> > the
> > > >> server has stopped before returning.
> > > >>
> > > >> On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson 
> > wrote:
> > > >>
> > > >>> Hello All,
> > > >>>
> > > >>> I would like to propose that we make the gfsh “stop server” command
> > > >>> synchronous. It is causing some issues with some tests as the rest
> of
> > > the
> > > >>> calls are blocking. Stop on the other hand immediately returns by
> > > >>> comparison.
> > > >>> This causes issues as shown in GEODE-7017 specifically.
> > > >>>
> > > >>> GEODE:7017 CI failure:
> > > >>>
> > org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> > > >>> startupReportsOnlineOnlyAfterRedundancyRestored
> > > >>> https://issues.apache.org/jira/browse/GEODE-7017 <
> > > >>> https://issues.apache.org/jira/browse/GEODE-7017>
> > > >>>
> > > >>>
> > > >>> What do people think?
> > > >>>
> > > >>> Thanks,
> > > >>> Mark
> > > >>
> > > >
> > > >
> > > > --
> > > > -John
> > > > john.blum10101 (skype)
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

@Anil-  I hear your argument when you are "scripting" with *Gfsh*, but
blocking absolutely maybe less desirable when using *Gfsh* interactively.
There are, after all, many non-cluster based commands.

@Mark - I see.  I have generally found in my own testing purposes,
especially automated, that a cache instance is not fully closed and has not
properly released all it's resource even after cache.close() returns.

-j

On Tue, Sep 10, 2019 at 5:02 PM Mark Hanson  wrote:

> Hi John,
>
> Kirk and I found that in our testing it was returning before it was fully
> stopped. I have a change that seems viable that waits for the pid file to
> disappear from the subdirectory of the server. I am not a fan. I would
> prefer to wait for the pid to disappear, but that doesn’t seem like it will
> be cross-platform friendly.
>
> Thanks,
> Mark
>
> > On Sep 10, 2019, at 3:31 PM, John Blum  wrote:
> >
> > `stop server` is synchronous (with an option to break out of the wait
> using
> > CTRL^C) AFAIR.
> >
> > Way deep down inside, it simply relies on GemFireCache.close() to return
> > (in-process).
> >
> > As Darrel mentioned, there is not "true" signal the the server was
> > successfully stopped.
> >
> > -j
> >
> >
> > On Tue, Sep 10, 2019 at 3:23 PM Darrel Schneider 
> > wrote:
> >
> >> I think it would be good for stop server to confirm in some way that the
> >> server has stopped before returning.
> >>
> >> On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson  wrote:
> >>
> >>> Hello All,
> >>>
> >>> I would like to propose that we make the gfsh “stop server” command
> >>> synchronous. It is causing some issues with some tests as the rest of
> the
> >>> calls are blocking. Stop on the other hand immediately returns by
> >>> comparison.
> >>> This causes issues as shown in GEODE-7017 specifically.
> >>>
> >>> GEODE:7017 CI failure:
> >>> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> >>> startupReportsOnlineOnlyAfterRedundancyRestored
> >>> https://issues.apache.org/jira/browse/GEODE-7017 <
> >>> https://issues.apache.org/jira/browse/GEODE-7017>
> >>>
> >>>
> >>> What do people think?
> >>>
> >>> Thanks,
> >>> Mark
> >>
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
>
>

-- 
-John
john.blum10101 (skype)

Re: [Proposal] Make gfsh "stop server" command synchronous

[John Blum]

`stop server` is synchronous (with an option to break out of the wait using
CTRL^C) AFAIR.

Way deep down inside, it simply relies on GemFireCache.close() to return
(in-process).

As Darrel mentioned, there is not "true" signal the the server was
successfully stopped.

-j


On Tue, Sep 10, 2019 at 3:23 PM Darrel Schneider 
wrote:

> I think it would be good for stop server to confirm in some way that the
> server has stopped before returning.
>
> On Tue, Sep 10, 2019 at 3:08 PM Mark Hanson  wrote:
>
> > Hello All,
> >
> > I would like to propose that we make the gfsh “stop server” command
> > synchronous. It is causing some issues with some tests as the rest of the
> > calls are blocking. Stop on the other hand immediately returns by
> > comparison.
> > This causes issues as shown in GEODE-7017 specifically.
> >
> > GEODE:7017 CI failure:
> > org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> > startupReportsOnlineOnlyAfterRedundancyRestored
> > https://issues.apache.org/jira/browse/GEODE-7017 <
> > https://issues.apache.org/jira/browse/GEODE-7017>
> >
> >
> > What do people think?
> >
> > Thanks,
> > Mark
>


-- 
-John
john.blum10101 (skype)

Re: [ANNOUNCE] Apache Geode 1.9.1

[John Blum]

Congrats Geode Community!

On Fri, Sep 6, 2019 at 11:04 AM Owen Nichols  wrote:

> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.9.1.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> Geode 1.9.1 improves compatibility with the Spring Data project and fixes a
> performance issue when SSL is enabled.  Users are encouraged to upgrade to
> the latest release.  For the full list of changes please review the release
> notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
>
> The release artifacts can be downloaded from the project website:
> http://geode.apache.org/releases/
>
> The release documentation is available at:
> http://geode.apache.org/docs/guide/19/about_geode.html
>
> We would like to thank all the contributors that made the release possible.
> Regards,
> Owen Nichols and Kirk Lund on behalf of the Apache Geode team
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1.RC3

[John Blum]

1 more thing...

I would additionally advise rewording the sentence...

*> Please add log4j-core to the classpath.*

To read...

"*Please consider adding log4j-core, or another Logging provider (e.g.
Logback), to your classpath.  Apache Geode works best with Log4j.*"

Food for thought.

-John


On Tue, Sep 3, 2019 at 10:40 AM John Blum  wrote:

> +1
>
> Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3).
>
> However, can we seriously reconsider logging the follow message at ERROR?
> Ugh!
>
> ERROR StatusLogger Log4j2 could not find a logging implementation. Please
> add log4j-core to the classpath. Using SimpleLogger to log to the console...
>
> WARN is more than sufficient.  If no logging provider is on the CLASSPATH,
> it creates a lot of noise!
>
> -John
>
>
> On Fri, Aug 30, 2019 at 12:27 PM Dave Barnes  wrote:
>
>> +1
>> Checked the docs: Successfully built viewed the Geode User Guide and the
>> Javadocs.
>>
>> On Fri, Aug 30, 2019 at 11:11 AM Owen Nichols 
>> wrote:
>>
>> > Hello Geode dev community,
>> >
>> > This is a release candidate for Apache Geode, version 1.9.1.RC3.
>> > Thanks to all the community members for their contributions to this
>> > release!
>> >
>> > Please do a review and give your feedback. The deadline is 3PM PST Thu,
>> > September 05 2019.
>> > Release notes can be found at:
>> >
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
>> >
>> > Please note that we are voting upon the source tags: rel/v1.9.1.RC3
>> >
>> > Apache Geode:
>> > https://github.com/apache/geode/tree/rel/v1.9.1.RC3
>> > Apache Geode examples:
>> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC3
>> > Apache Geode native:
>> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC3
>> >
>> > Source and binary files:
>> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3/
>> >
>> > Maven staging repo:
>> > https://repository.apache.org/content/repositories/orgapachegeode-1057
>> >
>> > Geode's KEYS file containing PGP keys we use to sign the release:
>> > https://github.com/apache/geode/blob/develop/KEYS
>> >
>> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
>> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3
>> > -PgeodeRepositoryUrl=
>> > https://repository.apache.org/content/repositories/orgapachegeode-1057
>> > build runAll
>> >
>> > Regards
>> > Owen & Kirk
>> >
>> >
>>
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1.RC3

[John Blum]

+1

Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3).

However, can we seriously reconsider logging the follow message at ERROR?
Ugh!

ERROR StatusLogger Log4j2 could not find a logging implementation. Please
add log4j-core to the classpath. Using SimpleLogger to log to the console...

WARN is more than sufficient.  If no logging provider is on the CLASSPATH,
it creates a lot of noise!

-John


On Fri, Aug 30, 2019 at 12:27 PM Dave Barnes  wrote:

> +1
> Checked the docs: Successfully built viewed the Geode User Guide and the
> Javadocs.
>
> On Fri, Aug 30, 2019 at 11:11 AM Owen Nichols  wrote:
>
> > Hello Geode dev community,
> >
> > This is a release candidate for Apache Geode, version 1.9.1.RC3.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > Please do a review and give your feedback. The deadline is 3PM PST Thu,
> > September 05 2019.
> > Release notes can be found at:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >
> > Please note that we are voting upon the source tags: rel/v1.9.1.RC3
> >
> > Apache Geode:
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC3
> > Apache Geode examples:
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC3
> > Apache Geode native:
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC3
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1057
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3
> > -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1057
> > build runAll
> >
> > Regards
> > Owen & Kirk
> >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [VOTE] Apache Geode 1.9.1 RC2

[John Blum]

+1

On Thu, Aug 29, 2019 at 5:40 PM Udo Kohlmeyer  wrote:

> +1
>
> On 8/29/19 5:02 PM, Owen Nichols wrote:
> > Hello Geode dev community,
> >
> > This is a release candidate for Apache Geode, version 1.9.1.RC2.
> > Thanks to all the community members for their contributions to this
> release!
> >
> > Please do a review and give your feedback. The deadline is 3PM PST Wed,
> September 04 2019.
> > Release notes can be found at:
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> <
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >
> >
> > Please note that we are voting upon the source tags: rel/v1.9.1.RC2
> >
> > Apache Geode:
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC2 <
> https://github.com/apache/geode/tree/rel/v1.9.1.RC2>
> > Apache Geode examples:
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC2 <
> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC2>
> > Apache Geode native:
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC2 <
> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC2>
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC2/ <
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC2/>
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1056 <
> https://repository.apache.org/content/repositories/orgapachegeode-1056>
> >
> > 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>
> >
> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC2
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1056
> build runAll
> >
> > Regards
> > Owen & Kirk
>


-- 
-John
john.blum10101 (skype)