[DISCUSS] Geode dependency update process (review by 8/28/2019)

[Nicholas Vallely]

https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Geode+dependency+update+process

Here is the content of the wiki proposal above for a discussion:
Problem

We recently updated the dependencies for the log4j version used in Geode to
keep up with Spring Boot Data Geode's logging dependencies. As far as I
know, we do not have a process to keep dependencies up to date or regularly
scheduled updates to them. Currently, I believe this is handled ad-hoc
which hasn't necessarily caused any major issues but could.
Anti-GoalsSolution

*Directly after GA release of Geode minor version:*
The release manager for the most recently released version of Geode would
review any dependencies in the Geode project (presumably this will/could be
automated).

   - For a minor release, only minor version dependency updates should be
   considered
   - For a major release, major versions should be considered

The release manager would submit a PR to update dependencies and then the
community should pitch in to tackle any subsequent issues that arise from
the updating of dependencies. *Note the first time this happens maybe
painful*

*In-between releases:*
We keep doing what we are doing:

   - Ad-hoc dependency updates as necessary

*When a new release manager is chosen:*
The release manager would send out an email as the last call for dependency
updates that would coincide with a proposed release branch cut date. This
would give everyone a reminder that if they need to update a dependency
prior to the release there is limited time left in order to do so.
Changes and Additions to Public Interfaces

*n/a*
Performance Impact

*Potentially a new version of a dependency could cause a performance impact
and we should run a performance test suite on the recently released version
vs the updated dependency version*
Backwards Compatibility and Upgrade Path

*In a minor release, minor version dependency updates shouldn't cause
compatibility issues.*
Prior Art

*What would be the alternatives to the proposed solution? What would happen
if we don’t solve the problem? Why should this proposal be preferred?*

*If we continue to do this ad-hoc, there is a greater likelihood of CVE's
or mismatching versions of conflicts between Geode and dependent projects.*


*Nick*

[DISCUSS] Release Geode 1.9.1 with logging improvements

[Kirk Lund]

I'd like to discuss if and how we can release Geode 1.9.1 with logging
improvements. This is primarily to provide a patch release for Spring Data
Geode and Spring Boot to ensure a smoother User experience out-of-the box.
They have very near-future releases that need this as soon as possible.

The specific tickets and commits that would be back-ported are:

*1. GEODE-7058 Log4j-core dependency should be optional in geode-core*

commit 413800bc16d05df689a2af5c30797f180aad6088
Author: Kirk Lund 
Date:   Wed Aug 7 14:33:21 2019 -0700

GEODE-7058: Mark log4j-core optional in geode-core

Note: this change requires all commits from GEODE-2644 and GEODE-6122.

*2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*

commit e5c9c420f462149fd062847904e3435fbe99afb4
Author: Kirk Lund 
Date:   Thu Aug 8 18:17:32 2019 -0700

GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider (#3892)

This change prevents Geode from using Log4jAgent if Log4j Core is
present but not using Log4jProvider.

For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in the
   classpath.

By disabling Log4jAgent when other Log4j Providers are in use, this
prevents problems such as ClassCastExceptions when attemping to cast
loggers from org.apache.logging.slf4j.SLF4JLogger to
org.apache.logging.log4j.core.Logger to get the LoggerConfig or
LoggerContext.

Co-Authored-By: Aaron Lindsey 

*3. GEODE-6959 NPE if AlertAppender is not defined*

commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
Author: Kirk Lund 
Date:   Thu Aug 8 14:59:44 2019 -0700

GEODE-6959: Prevent NPE in GMSMembershipManager for null AlertAppender
(#3899)

If a custom log4j2.xml is used without specifying the Geode
AlertAppender,
GMSMembershipManager may throw a NullPointerException when invoking
AlertAppender.getInstance().stopSession() during a forceDisconnect. This
change prevents the NullPointerException allowing forceDisconnect to
finish.

Users using Spring Boot with Logback are more likely to hit this bug.

Co-authored-by: Mark Hanson mhan...@pivotal.io

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Bruce Schuchardt]

If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL 
communications with conserve-sockets=false is currently broken in 1.9.


On 8/13/19 9:25 AM, Kirk Lund wrote:

I'd like to discuss if and how we can release Geode 1.9.1 with logging
improvements. This is primarily to provide a patch release for Spring Data
Geode and Spring Boot to ensure a smoother User experience out-of-the box.
They have very near-future releases that need this as soon as possible.

The specific tickets and commits that would be back-ported are:

*1. GEODE-7058 Log4j-core dependency should be optional in geode-core*

commit 413800bc16d05df689a2af5c30797f180aad6088
Author: Kirk Lund 
Date:   Wed Aug 7 14:33:21 2019 -0700

 GEODE-7058: Mark log4j-core optional in geode-core

 Note: this change requires all commits from GEODE-2644 and GEODE-6122.

*2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*

commit e5c9c420f462149fd062847904e3435fbe99afb4
Author: Kirk Lund 
Date:   Thu Aug 8 18:17:32 2019 -0700

 GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider (#3892)

 This change prevents Geode from using Log4jAgent if Log4j Core is
 present but not using Log4jProvider.

 For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in the
classpath.

 By disabling Log4jAgent when other Log4j Providers are in use, this
 prevents problems such as ClassCastExceptions when attemping to cast
 loggers from org.apache.logging.slf4j.SLF4JLogger to
 org.apache.logging.log4j.core.Logger to get the LoggerConfig or
 LoggerContext.

 Co-Authored-By: Aaron Lindsey 

*3. GEODE-6959 NPE if AlertAppender is not defined*

commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
Author: Kirk Lund 
Date:   Thu Aug 8 14:59:44 2019 -0700

 GEODE-6959: Prevent NPE in GMSMembershipManager for null AlertAppender
(#3899)

 If a custom log4j2.xml is used without specifying the Geode
AlertAppender,
 GMSMembershipManager may throw a NullPointerException when invoking
 AlertAppender.getInstance().stopSession() during a forceDisconnect. This
 change prevents the NullPointerException allowing forceDisconnect to
finish.

 Users using Spring Boot with Logback are more likely to hit this bug.

 Co-authored-by: Mark Hanson mhan...@pivotal.io

Re: [DISCUSS] Geode dependency update process (review by 8/28/2019)

[Aaron Lindsey]

I like the idea of proactively updating dependencies after each release. For 
this to work we would have to know whether the next release will be a major or 
minor release directly after each GA release (so that we can bump either major 
or minor versions, as appropriate). How and when do we currently determine our 
major release cycle? Would we know at the time of a GA release whether the next 
release would be a major or minor release?

- Aaron

> On Aug 13, 2019, at 9:22 AM, Nicholas Vallely  wrote:
> 
> https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Geode+dependency+update+process
> 
> Here is the content of the wiki proposal above for a discussion:
> Problem
> 
> We recently updated the dependencies for the log4j version used in Geode to
> keep up with Spring Boot Data Geode's logging dependencies. As far as I
> know, we do not have a process to keep dependencies up to date or regularly
> scheduled updates to them. Currently, I believe this is handled ad-hoc
> which hasn't necessarily caused any major issues but could.
> Anti-GoalsSolution
> 
> *Directly after GA release of Geode minor version:*
> The release manager for the most recently released version of Geode would
> review any dependencies in the Geode project (presumably this will/could be
> automated).
> 
>   - For a minor release, only minor version dependency updates should be
>   considered
>   - For a major release, major versions should be considered
> 
> The release manager would submit a PR to update dependencies and then the
> community should pitch in to tackle any subsequent issues that arise from
> the updating of dependencies. *Note the first time this happens maybe
> painful*
> 
> *In-between releases:*
> We keep doing what we are doing:
> 
>   - Ad-hoc dependency updates as necessary
> 
> *When a new release manager is chosen:*
> The release manager would send out an email as the last call for dependency
> updates that would coincide with a proposed release branch cut date. This
> would give everyone a reminder that if they need to update a dependency
> prior to the release there is limited time left in order to do so.
> Changes and Additions to Public Interfaces
> 
> *n/a*
> Performance Impact
> 
> *Potentially a new version of a dependency could cause a performance impact
> and we should run a performance test suite on the recently released version
> vs the updated dependency version*
> Backwards Compatibility and Upgrade Path
> 
> *In a minor release, minor version dependency updates shouldn't cause
> compatibility issues.*
> Prior Art
> 
> *What would be the alternatives to the proposed solution? What would happen
> if we don’t solve the problem? Why should this proposal be preferred?*
> 
> *If we continue to do this ad-hoc, there is a greater likelihood of CVE's
> or mismatching versions of conflicts between Geode and dependent projects.*
> 
> 
> *Nick*

Re: [DISCUSS] Geode dependency update process (review by 8/28/2019)

[Jacob Barrett]

We can simply update all dependencies to their latest as long as within a major 
it doesn’t change the public API. We have tried to do this after releases, 
though sometimes that PR languishes for a while. There is no formal process 
though so formalizing it would be great. The release manager could just open a 
ticket that requests that all dependencies be updated, then anyone could jump 
on that ticket.

-Jake


> On Aug 13, 2019, at 9:38 AM, Aaron Lindsey  wrote:
> 
> I like the idea of proactively updating dependencies after each release. For 
> this to work we would have to know whether the next release will be a major 
> or minor release directly after each GA release (so that we can bump either 
> major or minor versions, as appropriate). How and when do we currently 
> determine our major release cycle? Would we know at the time of a GA release 
> whether the next release would be a major or minor release?
> 
> - Aaron
> 
>> On Aug 13, 2019, at 9:22 AM, Nicholas Vallely  wrote:
>> 
>> https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Geode+dependency+update+process
>> 
>> Here is the content of the wiki proposal above for a discussion:
>> Problem
>> 
>> We recently updated the dependencies for the log4j version used in Geode to
>> keep up with Spring Boot Data Geode's logging dependencies. As far as I
>> know, we do not have a process to keep dependencies up to date or regularly
>> scheduled updates to them. Currently, I believe this is handled ad-hoc
>> which hasn't necessarily caused any major issues but could.
>> Anti-GoalsSolution
>> 
>> *Directly after GA release of Geode minor version:*
>> The release manager for the most recently released version of Geode would
>> review any dependencies in the Geode project (presumably this will/could be
>> automated).
>> 
>>  - For a minor release, only minor version dependency updates should be
>>  considered
>>  - For a major release, major versions should be considered
>> 
>> The release manager would submit a PR to update dependencies and then the
>> community should pitch in to tackle any subsequent issues that arise from
>> the updating of dependencies. *Note the first time this happens maybe
>> painful*
>> 
>> *In-between releases:*
>> We keep doing what we are doing:
>> 
>>  - Ad-hoc dependency updates as necessary
>> 
>> *When a new release manager is chosen:*
>> The release manager would send out an email as the last call for dependency
>> updates that would coincide with a proposed release branch cut date. This
>> would give everyone a reminder that if they need to update a dependency
>> prior to the release there is limited time left in order to do so.
>> Changes and Additions to Public Interfaces
>> 
>> *n/a*
>> Performance Impact
>> 
>> *Potentially a new version of a dependency could cause a performance impact
>> and we should run a performance test suite on the recently released version
>> vs the updated dependency version*
>> Backwards Compatibility and Upgrade Path
>> 
>> *In a minor release, minor version dependency updates shouldn't cause
>> compatibility issues.*
>> Prior Art
>> 
>> *What would be the alternatives to the proposed solution? What would happen
>> if we don’t solve the problem? Why should this proposal be preferred?*
>> 
>> *If we continue to do this ad-hoc, there is a greater likelihood of CVE's
>> or mismatching versions of conflicts between Geode and dependent projects.*
>> 
>> 
>> *Nick*
> 

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

[Kirk Lund]

I guess we need at least one more vote to get this fix copied to the 1.10.0
release branch. We just confirmed that this fix is NOT on that branch yet.

On Thu, Aug 8, 2019 at 11:03 AM Juan José Ramos  wrote:

> +1
>
> On Thu, Aug 8, 2019 at 7:02 PM John Blum  wrote:
>
> > +1 for Kirk's changes in 1.10.  This will be critical for SD Neuman and
> > SBDG 1.3.
> >
> > On Thu, Aug 8, 2019 at 10:57 AM Owen Nichols 
> wrote:
> >
> > > Hi Kirk and Mark, thank you for bringing your concern.
> > >
> > > Our “critical fixes” rule allows critical fixes to be brought to the
> > > release branch by proposal on the dev list, as you have just done.  If
> > > there is consensus from the Geode community that this NPE fix satisfies
> > the
> > > “critical fixes” rule, Dick or I will be happy to bring it to the
> 1.10.0
> > > release branch.
> > >
> > > -Owen
> > >
> > > > On Aug 8, 2019, at 10:54 AM, Kirk Lund  wrote:
> > > >
> > > > I'd like to propose including the fix for GEODE-6959 in 1.10.0.
> > > >
> > > > Spring Boot users are very likely to hit this NPE during
> > forceDisconnect.
> > > >
> > > > If a custom log4j2.xml is used without specifying the Geode
> > > AlertAppender,
> > > > GMSMembershipManager may throw a NullPointerException when invoking
> > > > AlertAppender.getInstance().stopSession() during a forceDisconnect.
> > This
> > > > change prevents the NullPointerException allowing forceDisconnect to
> > > finish.
> > > > Tests are included with this fix.
> > > >
> > > > PR: https://github.com/apache/geode/pull/3899
> > > > GEODE-6959: NPE if AlertAppender is not defined
> > > >
> > > > Thanks,
> > > > Kirk and Mark
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 
>

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

[Aaron Lindsey]

+1

> On Aug 13, 2019, at 9:59 AM, Kirk Lund  wrote:
> 
> I guess we need at least one more vote to get this fix copied to the 1.10.0
> release branch. We just confirmed that this fix is NOT on that branch yet.
> 
> On Thu, Aug 8, 2019 at 11:03 AM Juan José Ramos  wrote:
> 
>> +1
>> 
>> On Thu, Aug 8, 2019 at 7:02 PM John Blum  wrote:
>> 
>>> +1 for Kirk's changes in 1.10.  This will be critical for SD Neuman and
>>> SBDG 1.3.
>>> 
>>> On Thu, Aug 8, 2019 at 10:57 AM Owen Nichols 
>> wrote:
>>> 
 Hi Kirk and Mark, thank you for bringing your concern.
 
 Our “critical fixes” rule allows critical fixes to be brought to the
 release branch by proposal on the dev list, as you have just done.  If
 there is consensus from the Geode community that this NPE fix satisfies
>>> the
 “critical fixes” rule, Dick or I will be happy to bring it to the
>> 1.10.0
 release branch.
 
 -Owen
 
> On Aug 8, 2019, at 10:54 AM, Kirk Lund  wrote:
> 
> I'd like to propose including the fix for GEODE-6959 in 1.10.0.
> 
> Spring Boot users are very likely to hit this NPE during
>>> forceDisconnect.
> 
> If a custom log4j2.xml is used without specifying the Geode
 AlertAppender,
> GMSMembershipManager may throw a NullPointerException when invoking
> AlertAppender.getInstance().stopSession() during a forceDisconnect.
>>> This
> change prevents the NullPointerException allowing forceDisconnect to
 finish.
> Tests are included with this fix.
> 
> PR: https://github.com/apache/geode/pull/3899
> GEODE-6959: NPE if AlertAppender is not defined
> 
> Thanks,
> Kirk and Mark
 
 
>>> 
>>> --
>>> -John
>>> john.blum10101 (skype)
>>> 
>> 
>> 
>> --
>> Juan José Ramos Cassella
>> Senior Technical Support Engineer
>> Email: jra...@pivotal.io
>> Office#: +353 21 4238611
>> Mobile#: +353 87 2074066
>> After Hours Contact#: +1 877 477 2269
>> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>> How to upload artifacts:
>> https://support.pivotal.io/hc/en-us/articles/204369073
>> How to escalate a ticket:
>> https://support.pivotal.io/hc/en-us/articles/203809556
>> 
>> [image: support]  [image: twitter]
>>  [image: linkedin]
>>  [image: facebook]
>>  [image: google plus]
>>  [image: youtube]
>> 
>> 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Aaron Lindsey]

Assuming Geode 1.10 is released with the three logging fixes in Kirk’s message, 
can the next GA release of Spring Boot Data Geode consume 1.10 instead of 1.9? 
Also, when would SBDG need this patch release by (whether we do a 1.9.1 release 
or 1.10 release)?

- Aaron

> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt  wrote:
> 
> If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL 
> communications with conserve-sockets=false is currently broken in 1.9.
> 
> On 8/13/19 9:25 AM, Kirk Lund wrote:
>> I'd like to discuss if and how we can release Geode 1.9.1 with logging
>> improvements. This is primarily to provide a patch release for Spring Data
>> Geode and Spring Boot to ensure a smoother User experience out-of-the box.
>> They have very near-future releases that need this as soon as possible.
>> 
>> The specific tickets and commits that would be back-ported are:
>> 
>> *1. GEODE-7058 Log4j-core dependency should be optional in geode-core*
>> 
>> commit 413800bc16d05df689a2af5c30797f180aad6088
>> Author: Kirk Lund 
>> Date:   Wed Aug 7 14:33:21 2019 -0700
>> 
>> GEODE-7058: Mark log4j-core optional in geode-core
>> 
>> Note: this change requires all commits from GEODE-2644 and GEODE-6122.
>> 
>> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*
>> 
>> commit e5c9c420f462149fd062847904e3435fbe99afb4
>> Author: Kirk Lund 
>> Date:   Thu Aug 8 18:17:32 2019 -0700
>> 
>> GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider (#3892)
>> 
>> This change prevents Geode from using Log4jAgent if Log4j Core is
>> present but not using Log4jProvider.
>> 
>> For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in the
>>classpath.
>> 
>> By disabling Log4jAgent when other Log4j Providers are in use, this
>> prevents problems such as ClassCastExceptions when attemping to cast
>> loggers from org.apache.logging.slf4j.SLF4JLogger to
>> org.apache.logging.log4j.core.Logger to get the LoggerConfig or
>> LoggerContext.
>> 
>> Co-Authored-By: Aaron Lindsey 
>> 
>> *3. GEODE-6959 NPE if AlertAppender is not defined*
>> 
>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
>> Author: Kirk Lund 
>> Date:   Thu Aug 8 14:59:44 2019 -0700
>> 
>> GEODE-6959: Prevent NPE in GMSMembershipManager for null AlertAppender
>> (#3899)
>> 
>> If a custom log4j2.xml is used without specifying the Geode
>> AlertAppender,
>> GMSMembershipManager may throw a NullPointerException when invoking
>> AlertAppender.getInstance().stopSession() during a forceDisconnect. This
>> change prevents the NullPointerException allowing forceDisconnect to
>> finish.
>> 
>> Users using Spring Boot with Logback are more likely to hit this bug.
>> 
>> Co-authored-by: Mark Hanson mhan...@pivotal.io
>> 

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

[Juan José Ramos]

+1

On Tue, Aug 13, 2019 at 6:03 PM Aaron Lindsey  wrote:

> +1
>
> > On Aug 13, 2019, at 9:59 AM, Kirk Lund  wrote:
> >
> > I guess we need at least one more vote to get this fix copied to the
> 1.10.0
> > release branch. We just confirmed that this fix is NOT on that branch
> yet.
> >
> > On Thu, Aug 8, 2019 at 11:03 AM Juan José Ramos 
> wrote:
> >
> >> +1
> >>
> >> On Thu, Aug 8, 2019 at 7:02 PM John Blum  wrote:
> >>
> >>> +1 for Kirk's changes in 1.10.  This will be critical for SD Neuman and
> >>> SBDG 1.3.
> >>>
> >>> On Thu, Aug 8, 2019 at 10:57 AM Owen Nichols 
> >> wrote:
> >>>
>  Hi Kirk and Mark, thank you for bringing your concern.
> 
>  Our “critical fixes” rule allows critical fixes to be brought to the
>  release branch by proposal on the dev list, as you have just done.  If
>  there is consensus from the Geode community that this NPE fix
> satisfies
> >>> the
>  “critical fixes” rule, Dick or I will be happy to bring it to the
> >> 1.10.0
>  release branch.
> 
>  -Owen
> 
> > On Aug 8, 2019, at 10:54 AM, Kirk Lund  wrote:
> >
> > I'd like to propose including the fix for GEODE-6959 in 1.10.0.
> >
> > Spring Boot users are very likely to hit this NPE during
> >>> forceDisconnect.
> >
> > If a custom log4j2.xml is used without specifying the Geode
>  AlertAppender,
> > GMSMembershipManager may throw a NullPointerException when invoking
> > AlertAppender.getInstance().stopSession() during a forceDisconnect.
> >>> This
> > change prevents the NullPointerException allowing forceDisconnect to
>  finish.
> > Tests are included with this fix.
> >
> > PR: https://github.com/apache/geode/pull/3899
> > GEODE-6959: NPE if AlertAppender is not defined
> >
> > Thanks,
> > Kirk and Mark
> 
> 
> >>>
> >>> --
> >>> -John
> >>> john.blum10101 (skype)
> >>>
> >>
> >>
> >> --
> >> Juan José Ramos Cassella
> >> Senior Technical Support Engineer
> >> Email: jra...@pivotal.io
> >> Office#: +353 21 4238611
> >> Mobile#: +353 87 2074066
> >> After Hours Contact#: +1 877 477 2269
> >> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> >> How to upload artifacts:
> >> https://support.pivotal.io/hc/en-us/articles/204369073
> >> How to escalate a ticket:
> >> https://support.pivotal.io/hc/en-us/articles/203809556
> >>
> >> [image: support]  [image: twitter]
> >>  [image: linkedin]
> >>  [image: facebook]
> >>  [image: google plus]
> >>  [image: youtube]
> >> <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
> >>
>
>

-- 
Juan José Ramos Cassella
Senior Software Engineer
Email: jra...@pivotal.io

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Udo Kohlmeyer]

The latest version of SBDG 1.2 is already in RC stage. Which means the 
dependent Geode version cannot be changed any more. Currently SBDG 1.2 
is based on Geode 1.9. This will not change. Patch versions to 1.9 are 
supported, but not changes to 1.10 or later.


THUS,

Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of 
Geode, which at this point would be 1.10 or possibly 1.11 depending on 
release cycles.


In addition...

@Aaron, Whilst it would also be possible to override the underlying 
Geode version that SBDG uses, to a later version, I would just like to 
point out that all testing of SBDG will be against a named supported 
version of Geode / GemFire. Which means, if failures arise using SBDG / 
SDG with a non-supported version of Geode / GemFire would effectively be 
unsupported. (due diligence to confirm origin of failure will of course 
be applied)


Hope this helps...

--Udo

On 8/13/19 10:03 AM, Aaron Lindsey wrote:

Assuming Geode 1.10 is released with the three logging fixes in Kirk’s message, 
can the next GA release of Spring Boot Data Geode consume 1.10 instead of 1.9? 
Also, when would SBDG need this patch release by (whether we do a 1.9.1 release 
or 1.10 release)?

- Aaron


On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt  wrote:

If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL 
communications with conserve-sockets=false is currently broken in 1.9.

On 8/13/19 9:25 AM, Kirk Lund wrote:

I'd like to discuss if and how we can release Geode 1.9.1 with logging
improvements. This is primarily to provide a patch release for Spring Data
Geode and Spring Boot to ensure a smoother User experience out-of-the box.
They have very near-future releases that need this as soon as possible.

The specific tickets and commits that would be back-ported are:

*1. GEODE-7058 Log4j-core dependency should be optional in geode-core*

commit 413800bc16d05df689a2af5c30797f180aad6088
Author: Kirk Lund 
Date:   Wed Aug 7 14:33:21 2019 -0700

 GEODE-7058: Mark log4j-core optional in geode-core

 Note: this change requires all commits from GEODE-2644 and GEODE-6122.

*2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*

commit e5c9c420f462149fd062847904e3435fbe99afb4
Author: Kirk Lund 
Date:   Thu Aug 8 18:17:32 2019 -0700

 GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider (#3892)

 This change prevents Geode from using Log4jAgent if Log4j Core is
 present but not using Log4jProvider.

 For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in the
classpath.

 By disabling Log4jAgent when other Log4j Providers are in use, this
 prevents problems such as ClassCastExceptions when attemping to cast
 loggers from org.apache.logging.slf4j.SLF4JLogger to
 org.apache.logging.log4j.core.Logger to get the LoggerConfig or
 LoggerContext.

 Co-Authored-By: Aaron Lindsey 

*3. GEODE-6959 NPE if AlertAppender is not defined*

commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
Author: Kirk Lund 
Date:   Thu Aug 8 14:59:44 2019 -0700

 GEODE-6959: Prevent NPE in GMSMembershipManager for null AlertAppender
(#3899)

 If a custom log4j2.xml is used without specifying the Geode
AlertAppender,
 GMSMembershipManager may throw a NullPointerException when invoking
 AlertAppender.getInstance().stopSession() during a forceDisconnect. This
 change prevents the NullPointerException allowing forceDisconnect to
finish.

 Users using Spring Boot with Logback are more likely to hit this bug.

 Co-authored-by: Mark Hanson mhan...@pivotal.io

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Kirk Lund]

Udo, Thanks for the info! Sounds like we shouldn't bother with Geode 1.9.1
then. If I'm misinterpreting what you wrote, let me know.

On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer  wrote:

> The latest version of SBDG 1.2 is already in RC stage. Which means the
> dependent Geode version cannot be changed any more. Currently SBDG 1.2
> is based on Geode 1.9. This will not change. Patch versions to 1.9 are
> supported, but not changes to 1.10 or later.
>
> THUS,
>
> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
> Geode, which at this point would be 1.10 or possibly 1.11 depending on
> release cycles.
>
> In addition...
>
> @Aaron, Whilst it would also be possible to override the underlying
> Geode version that SBDG uses, to a later version, I would just like to
> point out that all testing of SBDG will be against a named supported
> version of Geode / GemFire. Which means, if failures arise using SBDG /
> SDG with a non-supported version of Geode / GemFire would effectively be
> unsupported. (due diligence to confirm origin of failure will of course
> be applied)
>
> Hope this helps...
>
> --Udo
>
> On 8/13/19 10:03 AM, Aaron Lindsey wrote:
> > Assuming Geode 1.10 is released with the three logging fixes in Kirk’s
> message, can the next GA release of Spring Boot Data Geode consume 1.10
> instead of 1.9? Also, when would SBDG need this patch release by (whether
> we do a 1.9.1 release or 1.10 release)?
> >
> > - Aaron
> >
> >> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt 
> wrote:
> >>
> >> If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL
> communications with conserve-sockets=false is currently broken in 1.9.
> >>
> >> On 8/13/19 9:25 AM, Kirk Lund wrote:
> >>> I'd like to discuss if and how we can release Geode 1.9.1 with logging
> >>> improvements. This is primarily to provide a patch release for Spring
> Data
> >>> Geode and Spring Boot to ensure a smoother User experience out-of-the
> box.
> >>> They have very near-future releases that need this as soon as possible.
> >>>
> >>> The specific tickets and commits that would be back-ported are:
> >>>
> >>> *1. GEODE-7058 Log4j-core dependency should be optional in geode-core*
> >>>
> >>> commit 413800bc16d05df689a2af5c30797f180aad6088
> >>> Author: Kirk Lund 
> >>> Date:   Wed Aug 7 14:33:21 2019 -0700
> >>>
> >>>  GEODE-7058: Mark log4j-core optional in geode-core
> >>>
> >>>  Note: this change requires all commits from GEODE-2644 and
> GEODE-6122.
> >>>
> >>> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*
> >>>
> >>> commit e5c9c420f462149fd062847904e3435fbe99afb4
> >>> Author: Kirk Lund 
> >>> Date:   Thu Aug 8 18:17:32 2019 -0700
> >>>
> >>>  GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
> (#3892)
> >>>
> >>>  This change prevents Geode from using Log4jAgent if Log4j Core is
> >>>  present but not using Log4jProvider.
> >>>
> >>>  For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in
> the
> >>> classpath.
> >>>
> >>>  By disabling Log4jAgent when other Log4j Providers are in use,
> this
> >>>  prevents problems such as ClassCastExceptions when attemping to
> cast
> >>>  loggers from org.apache.logging.slf4j.SLF4JLogger to
> >>>  org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> >>>  LoggerContext.
> >>>
> >>>  Co-Authored-By: Aaron Lindsey 
> >>>
> >>> *3. GEODE-6959 NPE if AlertAppender is not defined*
> >>>
> >>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
> >>> Author: Kirk Lund 
> >>> Date:   Thu Aug 8 14:59:44 2019 -0700
> >>>
> >>>  GEODE-6959: Prevent NPE in GMSMembershipManager for null
> AlertAppender
> >>> (#3899)
> >>>
> >>>  If a custom log4j2.xml is used without specifying the Geode
> >>> AlertAppender,
> >>>  GMSMembershipManager may throw a NullPointerException when
> invoking
> >>>  AlertAppender.getInstance().stopSession() during a
> forceDisconnect. This
> >>>  change prevents the NullPointerException allowing forceDisconnect
> to
> >>> finish.
> >>>
> >>>  Users using Spring Boot with Logback are more likely to hit this
> bug.
> >>>
> >>>  Co-authored-by: Mark Hanson mhan...@pivotal.io
> >>>
>

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Anthony Baker]

I think there’s value is doing a 1.9.1 patch release to support Spring users.

Anthony


> On Aug 13, 2019, at 11:26 AM, Kirk Lund  wrote:
> 
> Udo, Thanks for the info! Sounds like we shouldn't bother with Geode 1.9.1
> then. If I'm misinterpreting what you wrote, let me know.
> 
> On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer  wrote:
> 
>> The latest version of SBDG 1.2 is already in RC stage. Which means the
>> dependent Geode version cannot be changed any more. Currently SBDG 1.2
>> is based on Geode 1.9. This will not change. Patch versions to 1.9 are
>> supported, but not changes to 1.10 or later.
>> 
>> THUS,
>> 
>> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
>> Geode, which at this point would be 1.10 or possibly 1.11 depending on
>> release cycles.
>> 
>> In addition...
>> 
>> @Aaron, Whilst it would also be possible to override the underlying
>> Geode version that SBDG uses, to a later version, I would just like to
>> point out that all testing of SBDG will be against a named supported
>> version of Geode / GemFire. Which means, if failures arise using SBDG /
>> SDG with a non-supported version of Geode / GemFire would effectively be
>> unsupported. (due diligence to confirm origin of failure will of course
>> be applied)
>> 
>> Hope this helps...
>> 
>> --Udo
>> 
>> On 8/13/19 10:03 AM, Aaron Lindsey wrote:
>>> Assuming Geode 1.10 is released with the three logging fixes in Kirk’s
>> message, can the next GA release of Spring Boot Data Geode consume 1.10
>> instead of 1.9? Also, when would SBDG need this patch release by (whether
>> we do a 1.9.1 release or 1.10 release)?
>>> 
>>> - Aaron
>>> 
 On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt 
>> wrote:
 
 If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL
>> communications with conserve-sockets=false is currently broken in 1.9.
 
 On 8/13/19 9:25 AM, Kirk Lund wrote:
> I'd like to discuss if and how we can release Geode 1.9.1 with logging
> improvements. This is primarily to provide a patch release for Spring
>> Data
> Geode and Spring Boot to ensure a smoother User experience out-of-the
>> box.
> They have very near-future releases that need this as soon as possible.
> 
> The specific tickets and commits that would be back-ported are:
> 
> *1. GEODE-7058 Log4j-core dependency should be optional in geode-core*
> 
> commit 413800bc16d05df689a2af5c30797f180aad6088
> Author: Kirk Lund 
> Date:   Wed Aug 7 14:33:21 2019 -0700
> 
> GEODE-7058: Mark log4j-core optional in geode-core
> 
> Note: this change requires all commits from GEODE-2644 and
>> GEODE-6122.
> 
> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*
> 
> commit e5c9c420f462149fd062847904e3435fbe99afb4
> Author: Kirk Lund 
> Date:   Thu Aug 8 18:17:32 2019 -0700
> 
> GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
>> (#3892)
> 
> This change prevents Geode from using Log4jAgent if Log4j Core is
> present but not using Log4jProvider.
> 
> For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in
>> the
>classpath.
> 
> By disabling Log4jAgent when other Log4j Providers are in use,
>> this
> prevents problems such as ClassCastExceptions when attemping to
>> cast
> loggers from org.apache.logging.slf4j.SLF4JLogger to
> org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> LoggerContext.
> 
> Co-Authored-By: Aaron Lindsey 
> 
> *3. GEODE-6959 NPE if AlertAppender is not defined*
> 
> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
> Author: Kirk Lund 
> Date:   Thu Aug 8 14:59:44 2019 -0700
> 
> GEODE-6959: Prevent NPE in GMSMembershipManager for null
>> AlertAppender
> (#3899)
> 
> If a custom log4j2.xml is used without specifying the Geode
> AlertAppender,
> GMSMembershipManager may throw a NullPointerException when
>> invoking
> AlertAppender.getInstance().stopSession() during a
>> forceDisconnect. This
> change prevents the NullPointerException allowing forceDisconnect
>> to
> finish.
> 
> Users using Spring Boot with Logback are more likely to hit this
>> bug.
> 
> Co-authored-by: Mark Hanson mhan...@pivotal.io
> 
>> 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Bruce Schuchardt]

+1

On 8/13/19 11:55 AM, Anthony Baker wrote:

I think there’s value is doing a 1.9.1 patch release to support Spring users.

Anthony



On Aug 13, 2019, at 11:26 AM, Kirk Lund  wrote:

Udo, Thanks for the info! Sounds like we shouldn't bother with Geode 1.9.1
then. If I'm misinterpreting what you wrote, let me know.

On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer  wrote:


The latest version of SBDG 1.2 is already in RC stage. Which means the
dependent Geode version cannot be changed any more. Currently SBDG 1.2
is based on Geode 1.9. This will not change. Patch versions to 1.9 are
supported, but not changes to 1.10 or later.

THUS,

Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
Geode, which at this point would be 1.10 or possibly 1.11 depending on
release cycles.

In addition...

@Aaron, Whilst it would also be possible to override the underlying
Geode version that SBDG uses, to a later version, I would just like to
point out that all testing of SBDG will be against a named supported
version of Geode / GemFire. Which means, if failures arise using SBDG /
SDG with a non-supported version of Geode / GemFire would effectively be
unsupported. (due diligence to confirm origin of failure will of course
be applied)

Hope this helps...

--Udo

On 8/13/19 10:03 AM, Aaron Lindsey wrote:

Assuming Geode 1.10 is released with the three logging fixes in Kirk’s

message, can the next GA release of Spring Boot Data Geode consume 1.10
instead of 1.9? Also, when would SBDG need this patch release by (whether
we do a 1.9.1 release or 1.10 release)?

- Aaron


On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt 

wrote:

If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL

communications with conserve-sockets=false is currently broken in 1.9.

On 8/13/19 9:25 AM, Kirk Lund wrote:

I'd like to discuss if and how we can release Geode 1.9.1 with logging
improvements. This is primarily to provide a patch release for Spring

Data

Geode and Spring Boot to ensure a smoother User experience out-of-the

box.

They have very near-future releases that need this as soon as possible.

The specific tickets and commits that would be back-ported are:

*1. GEODE-7058 Log4j-core dependency should be optional in geode-core*

commit 413800bc16d05df689a2af5c30797f180aad6088
Author: Kirk Lund 
Date:   Wed Aug 7 14:33:21 2019 -0700

 GEODE-7058: Mark log4j-core optional in geode-core

 Note: this change requires all commits from GEODE-2644 and

GEODE-6122.

*2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*

commit e5c9c420f462149fd062847904e3435fbe99afb4
Author: Kirk Lund 
Date:   Thu Aug 8 18:17:32 2019 -0700

 GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider

(#3892)

 This change prevents Geode from using Log4jAgent if Log4j Core is
 present but not using Log4jProvider.

 For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in

the

classpath.

 By disabling Log4jAgent when other Log4j Providers are in use,

this

 prevents problems such as ClassCastExceptions when attemping to

cast

 loggers from org.apache.logging.slf4j.SLF4JLogger to
 org.apache.logging.log4j.core.Logger to get the LoggerConfig or
 LoggerContext.

 Co-Authored-By: Aaron Lindsey 

*3. GEODE-6959 NPE if AlertAppender is not defined*

commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
Author: Kirk Lund 
Date:   Thu Aug 8 14:59:44 2019 -0700

 GEODE-6959: Prevent NPE in GMSMembershipManager for null

AlertAppender

(#3899)

 If a custom log4j2.xml is used without specifying the Geode
AlertAppender,
 GMSMembershipManager may throw a NullPointerException when

invoking

 AlertAppender.getInstance().stopSession() during a

forceDisconnect. This

 change prevents the NullPointerException allowing forceDisconnect

to

finish.

 Users using Spring Boot with Logback are more likely to hit this

bug.

 Co-authored-by: Mark Hanson mhan...@pivotal.io

Re: Draft of Apache Geode Quarterly Report (Aug 2019) for your review

[Anthony Baker]

I think you could call out a number of interesting discussions that happened on 
the dev list:

- CFP process
- Criteria for being a committer
- etc

Anthony


> On Aug 12, 2019, at 4:26 PM, Dave Barnes  wrote:
> 
> Thanks, Aaron - good catch.
> 
> On Mon, Aug 12, 2019 at 4:09 PM Aaron Lindsey  wrote:
> 
>> Kind of a small thing, but the Committer-to-PMC ratio seems more like 2:1
>> based on the numbers of committers and PMC members below.
>> 
>> - Aaron
>> 
>>> On Aug 12, 2019, at 2:22 PM, Dave Barnes  wrote:
>>> 
>>> Reformatted for more amenable viewing:
>>> 
>>> ## Description:
>>> 
>>> The mission of Apache Geode is the creation and maintenance of software
>>> related
>>> 
>>> to a data management platform that provides real-time, consistent access
>> to
>>> 
>>> data-intensive applications throughout widely distributed cloud
>>> architectures.
>>> 
>>> 
>>> ## Issues:
>>> 
>>> There are no issues requiring board attention at this time.
>>> 
>>> 
>>> ## Membership Data:
>>> 
>>> Apache Geode was founded 2016-11-15 (3 years ago) There are currently 102
>>> 
>>> committers and 50 PMC members in this project. The Committer-to-PMC
>> ratio is
>>> 
>>> roughly 7:4.
>>> 
>>> 
>>> Community changes, past quarter:
>>> 
>>> - No new PMC members. Last additions were Juan Ramos and Robert Houghton
>> on
>>> 
>>> 2019-02-20
>>> 
>>> - Dale Emery was added as committer on 2019-06-19
>>> 
>>> - Mark Hanson was added as committer on 2019-06-19
>>> 
>>> 
>>> ## Project Activity:
>>> 
>>> Release 1.10 is in progress.
>>> 
>>> 
>>> An Apache Geode Summit is scheduled the day before the SpringOne Platform
>>> 2019
>>> 
>>> conference, on 7 October 2019, in Austin, TX. Several Geode contributors
>>> will
>>> 
>>> present talks and sessions aimed at a variety of levels.
>>> 
>>> 
>>> ## Community Health:
>>> 
>>> Mailing lists remain active and productive.
>>> 
>>> - dev@geode.apache.org had a 13% increase in traffic in the past
>> quarter
>>> 
>>> (505 emails compared to 443)
>>> 
>>> 
>>> JIRA tickets show that issues continue to be identified and resolved.
>>> 
>>> - 289 issues opened in JIRA in the past quarter
>>> 
>>> - 296 issues closed in   JIRA in the past quarter
>>> 
>>> - 454 commits in the past quarter
>>> 
>>> 
>>> The community is actively contributing to the Apache Geode code base:
>>> 
>>> - 62 code contributors in the past quarter
>>> 
>>> - 344 PRs opened on GitHub in the past quarter
>>> 
>>> - 356 PRs closed on GitHub in the past quarter
>>> 
>>> On Mon, Aug 12, 2019 at 2:10 PM Dave Barnes  wrote:
>>> 
 Please review by Noon PDT, Tuesday, Aug 13. Thanks!
 
 ## Description:
 
 The mission of Apache Geode is the creation and maintenance of software
 related
 to a data management platform that provides real-time, consistent access
 to
 data-intensive applications throughout widely distributed cloud
 architectures.
 
 ## Issues: There are no issues requiring board attention at this time.
>> ##
 Membership Data: Apache Geode was founded 2016-11-15 (3 years ago) There
 are currently 102 committers and 50 PMC members in this project. The
 Committer-to-PMC ratio is roughly 7:4. Community changes, past quarter:
>> -
 No new PMC members. Last additions were Juan Ramos and Robert Houghton
>> on
 2019-02-20 - Dale Emery was added as committer on 2019-06-19 - Mark
>> Hanson
 was added as committer on 2019-06-19 ## Project Activity: Release 1.10
>> is
 in progress. An Apache Geode Summit is scheduled the day before the
 SpringOne Platform 2019 conference, on 7 October 2019, in Austin, TX.
 Several Geode contributors will present talks and in traffic in the past
 quarter (505 emails compared to 443) JIRA tickets show that issues
>> continue
 to be identified and resolved. - 289 issues opened in JIRA in the past
 quarter - 296 issues closed in JIRA in the past quarter - 454 commits in
 the past quarter The community is actively contributing to the Apache
 Geode code base: - 62 code contributors in the past quarter - 344 PRs
 opened on GitHub in the past quarter - 356 PRs closed on GitHub in the
>> past
 quarter
 
>> 
>> 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Jens Deppe]

This would then imply a SBDG 1.2.1 to include Geode 1.9.1.

On Tue, Aug 13, 2019 at 11:55 AM Anthony Baker  wrote:

> I think there’s value is doing a 1.9.1 patch release to support Spring
> users.
>
> Anthony
>
>
> > On Aug 13, 2019, at 11:26 AM, Kirk Lund  wrote:
> >
> > Udo, Thanks for the info! Sounds like we shouldn't bother with Geode
> 1.9.1
> > then. If I'm misinterpreting what you wrote, let me know.
> >
> > On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer  wrote:
> >
> >> The latest version of SBDG 1.2 is already in RC stage. Which means the
> >> dependent Geode version cannot be changed any more. Currently SBDG 1.2
> >> is based on Geode 1.9. This will not change. Patch versions to 1.9 are
> >> supported, but not changes to 1.10 or later.
> >>
> >> THUS,
> >>
> >> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
> >> Geode, which at this point would be 1.10 or possibly 1.11 depending on
> >> release cycles.
> >>
> >> In addition...
> >>
> >> @Aaron, Whilst it would also be possible to override the underlying
> >> Geode version that SBDG uses, to a later version, I would just like to
> >> point out that all testing of SBDG will be against a named supported
> >> version of Geode / GemFire. Which means, if failures arise using SBDG /
> >> SDG with a non-supported version of Geode / GemFire would effectively be
> >> unsupported. (due diligence to confirm origin of failure will of course
> >> be applied)
> >>
> >> Hope this helps...
> >>
> >> --Udo
> >>
> >> On 8/13/19 10:03 AM, Aaron Lindsey wrote:
> >>> Assuming Geode 1.10 is released with the three logging fixes in Kirk’s
> >> message, can the next GA release of Spring Boot Data Geode consume 1.10
> >> instead of 1.9? Also, when would SBDG need this patch release by
> (whether
> >> we do a 1.9.1 release or 1.10 release)?
> >>>
> >>> - Aaron
> >>>
>  On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt  >
> >> wrote:
> 
>  If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL
> >> communications with conserve-sockets=false is currently broken in 1.9.
> 
>  On 8/13/19 9:25 AM, Kirk Lund wrote:
> > I'd like to discuss if and how we can release Geode 1.9.1 with
> logging
> > improvements. This is primarily to provide a patch release for Spring
> >> Data
> > Geode and Spring Boot to ensure a smoother User experience out-of-the
> >> box.
> > They have very near-future releases that need this as soon as
> possible.
> >
> > The specific tickets and commits that would be back-ported are:
> >
> > *1. GEODE-7058 Log4j-core dependency should be optional in
> geode-core*
> >
> > commit 413800bc16d05df689a2af5c30797f180aad6088
> > Author: Kirk Lund 
> > Date:   Wed Aug 7 14:33:21 2019 -0700
> >
> > GEODE-7058: Mark log4j-core optional in geode-core
> >
> > Note: this change requires all commits from GEODE-2644 and
> >> GEODE-6122.
> >
> > *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*
> >
> > commit e5c9c420f462149fd062847904e3435fbe99afb4
> > Author: Kirk Lund 
> > Date:   Thu Aug 8 18:17:32 2019 -0700
> >
> > GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
> >> (#3892)
> >
> > This change prevents Geode from using Log4jAgent if Log4j Core is
> > present but not using Log4jProvider.
> >
> > For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in
> >> the
> >classpath.
> >
> > By disabling Log4jAgent when other Log4j Providers are in use,
> >> this
> > prevents problems such as ClassCastExceptions when attemping to
> >> cast
> > loggers from org.apache.logging.slf4j.SLF4JLogger to
> > org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> > LoggerContext.
> >
> > Co-Authored-By: Aaron Lindsey 
> >
> > *3. GEODE-6959 NPE if AlertAppender is not defined*
> >
> > commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
> > Author: Kirk Lund 
> > Date:   Thu Aug 8 14:59:44 2019 -0700
> >
> > GEODE-6959: Prevent NPE in GMSMembershipManager for null
> >> AlertAppender
> > (#3899)
> >
> > If a custom log4j2.xml is used without specifying the Geode
> > AlertAppender,
> > GMSMembershipManager may throw a NullPointerException when
> >> invoking
> > AlertAppender.getInstance().stopSession() during a
> >> forceDisconnect. This
> > change prevents the NullPointerException allowing forceDisconnect
> >> to
> > finish.
> >
> > Users using Spring Boot with Logback are more likely to hit this
> >> bug.
> >
> > Co-authored-by: Mark Hanson mhan...@pivotal.io
> >
> >>
>
>

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Udo Kohlmeyer]

No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd have to 
wait for SBDG 1.3 to use 1.10 or 1.11


SBDG 1.3 is still a few months off, so maybe getting critical fixes in 
patch versions is required.


On 8/13/19 11:26 AM, Kirk Lund wrote:

Udo, Thanks for the info! Sounds like we shouldn't bother with Geode 1.9.1
then. If I'm misinterpreting what you wrote, let me know.

On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer  wrote:


The latest version of SBDG 1.2 is already in RC stage. Which means the
dependent Geode version cannot be changed any more. Currently SBDG 1.2
is based on Geode 1.9. This will not change. Patch versions to 1.9 are
supported, but not changes to 1.10 or later.

THUS,

Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
Geode, which at this point would be 1.10 or possibly 1.11 depending on
release cycles.

In addition...

@Aaron, Whilst it would also be possible to override the underlying
Geode version that SBDG uses, to a later version, I would just like to
point out that all testing of SBDG will be against a named supported
version of Geode / GemFire. Which means, if failures arise using SBDG /
SDG with a non-supported version of Geode / GemFire would effectively be
unsupported. (due diligence to confirm origin of failure will of course
be applied)

Hope this helps...

--Udo

On 8/13/19 10:03 AM, Aaron Lindsey wrote:

Assuming Geode 1.10 is released with the three logging fixes in Kirk’s

message, can the next GA release of Spring Boot Data Geode consume 1.10
instead of 1.9? Also, when would SBDG need this patch release by (whether
we do a 1.9.1 release or 1.10 release)?

- Aaron


On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt 

wrote:

If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL

communications with conserve-sockets=false is currently broken in 1.9.

On 8/13/19 9:25 AM, Kirk Lund wrote:

I'd like to discuss if and how we can release Geode 1.9.1 with logging
improvements. This is primarily to provide a patch release for Spring

Data

Geode and Spring Boot to ensure a smoother User experience out-of-the

box.

They have very near-future releases that need this as soon as possible.

The specific tickets and commits that would be back-ported are:

*1. GEODE-7058 Log4j-core dependency should be optional in geode-core*

commit 413800bc16d05df689a2af5c30797f180aad6088
Author: Kirk Lund 
Date:   Wed Aug 7 14:33:21 2019 -0700

  GEODE-7058: Mark log4j-core optional in geode-core

  Note: this change requires all commits from GEODE-2644 and

GEODE-6122.

*2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*

commit e5c9c420f462149fd062847904e3435fbe99afb4
Author: Kirk Lund 
Date:   Thu Aug 8 18:17:32 2019 -0700

  GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider

(#3892)

  This change prevents Geode from using Log4jAgent if Log4j Core is
  present but not using Log4jProvider.

  For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in

the

 classpath.

  By disabling Log4jAgent when other Log4j Providers are in use,

this

  prevents problems such as ClassCastExceptions when attemping to

cast

  loggers from org.apache.logging.slf4j.SLF4JLogger to
  org.apache.logging.log4j.core.Logger to get the LoggerConfig or
  LoggerContext.

  Co-Authored-By: Aaron Lindsey 

*3. GEODE-6959 NPE if AlertAppender is not defined*

commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
Author: Kirk Lund 
Date:   Thu Aug 8 14:59:44 2019 -0700

  GEODE-6959: Prevent NPE in GMSMembershipManager for null

AlertAppender

(#3899)

  If a custom log4j2.xml is used without specifying the Geode
AlertAppender,
  GMSMembershipManager may throw a NullPointerException when

invoking

  AlertAppender.getInstance().stopSession() during a

forceDisconnect. This

  change prevents the NullPointerException allowing forceDisconnect

to

finish.

  Users using Spring Boot with Logback are more likely to hit this

bug.

  Co-authored-by: Mark Hanson mhan...@pivotal.io

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Aaron Lindsey]

Thanks, Udo.

+1 for doing a 1.9.1 patch release, assuming there is enough time for SBDG to 
include it in their 1.2.x line.

- Aaron 

> On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer  wrote:
> 
> No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd have to wait 
> for SBDG 1.3 to use 1.10 or 1.11
> 
> SBDG 1.3 is still a few months off, so maybe getting critical fixes in patch 
> versions is required.
> 
> On 8/13/19 11:26 AM, Kirk Lund wrote:
>> Udo, Thanks for the info! Sounds like we shouldn't bother with Geode 1.9.1
>> then. If I'm misinterpreting what you wrote, let me know.
>> 
>> On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer  wrote:
>> 
>>> The latest version of SBDG 1.2 is already in RC stage. Which means the
>>> dependent Geode version cannot be changed any more. Currently SBDG 1.2
>>> is based on Geode 1.9. This will not change. Patch versions to 1.9 are
>>> supported, but not changes to 1.10 or later.
>>> 
>>> THUS,
>>> 
>>> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
>>> Geode, which at this point would be 1.10 or possibly 1.11 depending on
>>> release cycles.
>>> 
>>> In addition...
>>> 
>>> @Aaron, Whilst it would also be possible to override the underlying
>>> Geode version that SBDG uses, to a later version, I would just like to
>>> point out that all testing of SBDG will be against a named supported
>>> version of Geode / GemFire. Which means, if failures arise using SBDG /
>>> SDG with a non-supported version of Geode / GemFire would effectively be
>>> unsupported. (due diligence to confirm origin of failure will of course
>>> be applied)
>>> 
>>> Hope this helps...
>>> 
>>> --Udo
>>> 
>>> On 8/13/19 10:03 AM, Aaron Lindsey wrote:
 Assuming Geode 1.10 is released with the three logging fixes in Kirk’s
>>> message, can the next GA release of Spring Boot Data Geode consume 1.10
>>> instead of 1.9? Also, when would SBDG need this patch release by (whether
>>> we do a 1.9.1 release or 1.10 release)?
 - Aaron
 
> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt 
>>> wrote:
> If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL
>>> communications with conserve-sockets=false is currently broken in 1.9.
> On 8/13/19 9:25 AM, Kirk Lund wrote:
>> I'd like to discuss if and how we can release Geode 1.9.1 with logging
>> improvements. This is primarily to provide a patch release for Spring
>>> Data
>> Geode and Spring Boot to ensure a smoother User experience out-of-the
>>> box.
>> They have very near-future releases that need this as soon as possible.
>> 
>> The specific tickets and commits that would be back-ported are:
>> 
>> *1. GEODE-7058 Log4j-core dependency should be optional in geode-core*
>> 
>> commit 413800bc16d05df689a2af5c30797f180aad6088
>> Author: Kirk Lund 
>> Date:   Wed Aug 7 14:33:21 2019 -0700
>> 
>>  GEODE-7058: Mark log4j-core optional in geode-core
>> 
>>  Note: this change requires all commits from GEODE-2644 and
>>> GEODE-6122.
>> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*
>> 
>> commit e5c9c420f462149fd062847904e3435fbe99afb4
>> Author: Kirk Lund 
>> Date:   Thu Aug 8 18:17:32 2019 -0700
>> 
>>  GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
>>> (#3892)
>>  This change prevents Geode from using Log4jAgent if Log4j Core is
>>  present but not using Log4jProvider.
>> 
>>  For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in
>>> the
>> classpath.
>> 
>>  By disabling Log4jAgent when other Log4j Providers are in use,
>>> this
>>  prevents problems such as ClassCastExceptions when attemping to
>>> cast
>>  loggers from org.apache.logging.slf4j.SLF4JLogger to
>>  org.apache.logging.log4j.core.Logger to get the LoggerConfig or
>>  LoggerContext.
>> 
>>  Co-Authored-By: Aaron Lindsey 
>> 
>> *3. GEODE-6959 NPE if AlertAppender is not defined*
>> 
>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
>> Author: Kirk Lund 
>> Date:   Thu Aug 8 14:59:44 2019 -0700
>> 
>>  GEODE-6959: Prevent NPE in GMSMembershipManager for null
>>> AlertAppender
>> (#3899)
>> 
>>  If a custom log4j2.xml is used without specifying the Geode
>> AlertAppender,
>>  GMSMembershipManager may throw a NullPointerException when
>>> invoking
>>  AlertAppender.getInstance().stopSession() during a
>>> forceDisconnect. This
>>  change prevents the NullPointerException allowing forceDisconnect
>>> to
>> finish.
>> 
>>  Users using Spring Boot with Logback are more likely to hit this
>>> bug.
>>  Co-authored-by: Mark Hanson mhan...@pivotal.io
>> 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

For clarification...

1. SBDG 1.1 is the "*current*" development line (on

master

[1]);
SBDG 1.2 is *not* yet in development.
2. SBDG 1.1 is at RC1
 [2].
3. SBDG 1.1 is based on Spring Boot 2.1

[3]
and Spring Data (Geode) Lovelace

[4]
(or SDG 2.1

[5]);
This is not arbitrary because all the stars (bits, transitive dependency
versions) must "align" as defined by what Spring Boot 2.1 declares, and
Spring Boot 2.1 is based on

[6]
Spring Data Lovelace/2.1.
4. Spring Data Geode (SDG) Lovelace/2.1 is based on

[7]
Apache Geode 1.6.
5. All SDG Lovelace/2.1.x versions will always be based on the latest
Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
This ship has sailed.



6. SBDG 1.2, when it reaches development (soon),will be based on Spring
Boot 2.2

[8],
Spring Data (Geode) Moore

[9]
(or SDG 2.2

[10]);
This is also not arbitrary because Spring Boot 2.2 declares a dependency on

[11]
Spring Data Moore.  Again, the stars must align.
7. Spring Data Geode (SDG) Moore/2.2 is based on

[12]
Apache Geode 1.9.0.
8. As you can see, SDG Moore/2.2 is already in release candidates (i.e. RC2
or the 2nd release candidate), which means SDG cannot be rebased on 1.10 at
this point.  The transitive dependency major.minor versions are now fixed
for SD(G) Moore/2.2.
9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g. 1.9.1
up to  1.9.N where N is 0... infinity).

Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11 or
1.whatever is in the next SD Release Trains, Neuman, or 2.3.  SDG can
continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc
until SDG Neuman/2.3 reaches it's first release candidate (RC) release, at
which point the major.minor becomes fixed in that particular SD Release
Train, until the next SD Release Train (Neuman.next).

Make sense?

So, it is the SDG version (along with Spring Boot core) that SBDG depends
on that determines the version of Apache Geode that SBDG pulls in.

Hope this helps!

Regards,
John


[1]
https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
[2] https://github.com/spring-projects/spring-boot-data-geode/releases
[3]
https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
[4]
https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12
[5]
https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10
[6]
https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169
[7]
https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25
[8]
https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8
[9]
https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12
[10]
https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10
[11]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185
[12]
https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25


On Tue, Aug 13, 2019 at 12:40 PM Aaron Lindsey  wrote:

> Thanks, Udo.
>
> +1 for doing a 1.9.1 patch release, assuming there is enough time for SBDG
> to include it in their 1.2.x line.
>
> - Aaron
>
> > On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer  wrote:
> >
> > No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd have to
> wait for SBDG 1.3 to use 1.10 or 1.11
> >
> > SBDG 1.3 is still a few months off, so maybe getting critical fixes in
> patch versions is required.
> >
> > On 8/13/19 11:26 AM, Kirk Lund wrote:
> >> Udo, Thanks for the info! Sounds like we shouldn't bother with Geode
> 1.9.1
> >> then. If 

Failing LGTM Check

[Aaron Lindsey]

My PR has a LGTM check that shows “Failing” on the PR and LGTM site, but the 
LGTM logs say “Succeeded”:
Failing PR check: https://github.com/apache/geode/pull/3913/checks 

Failing check on LGTM site: 
https://lgtm.com/projects/g/apache/geode/rev/pr-f50cce2f02aa0f88f0d6beecbf236b29bc29683a
 

LGTM logs with “Succeeded” message: 
https://lgtm.com/projects/g/apache/geode/logs/rev/pr-f50cce2f02aa0f88f0d6beecbf236b29bc29683a/lang:java/stage:Preparing%20merge%20commit_6f1814d1f719cc06b13769c40a9d6d01f99f927c
 


How should I proceed with fixing this failing check?

- Aaron

Re: Failing LGTM Check

[Jacob Barrett]

I have a ticket open with LGTM on this issue. Just ignore it and move forward.

> On Aug 13, 2019, at 1:48 PM, Aaron Lindsey  wrote:
> 
> My PR has a LGTM check that shows “Failing” on the PR and LGTM site, but the 
> LGTM logs say “Succeeded”:
> Failing PR check: https://github.com/apache/geode/pull/3913/checks 
> 
> Failing check on LGTM site: 
> https://lgtm.com/projects/g/apache/geode/rev/pr-f50cce2f02aa0f88f0d6beecbf236b29bc29683a
>  
> 
> LGTM logs with “Succeeded” message: 
> https://lgtm.com/projects/g/apache/geode/logs/rev/pr-f50cce2f02aa0f88f0d6beecbf236b29bc29683a/lang:java/stage:Preparing%20merge%20commit_6f1814d1f719cc06b13769c40a9d6d01f99f927c
>  
> 
> 
> How should I proceed with fixing this failing check?
> 
> - Aaron

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

Stated slightly a different way...

If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then it
would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2
(which is and can only be Geode 1.9) for which SBDG is also based, along
with Spring Boot 2.2, which pulls in SD Moore/2.2 and therefore Geode 1.9
as well.  As such, the stars would not align and it would cause issues (or
unexpected surprises, possibly conflicts) for users of Spring Boot when
also using SBDG.  With SBDG, users of Spring Boot would get Geode 1.9 due
to the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
suddenly (possibly) change the Geode version to 1.10.  That is definitively
bad.

Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.

SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
available) which will pull in the latest version of Geode at that time
(e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC
status.

Cheers,
John




On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:

> For clarification...
>
> 1. SBDG 1.1 is the "*current*" development line (on
> 
> master
> 
>  [1]);
> SBDG 1.2 is *not* yet in development.
> 2. SBDG 1.1 is at RC1
>  [2].
> 3. SBDG 1.1 is based on Spring Boot 2.1
> 
>  [3]
> and Spring Data (Geode) Lovelace
> 
>  [4]
> (or SDG 2.1
> 
>  [5]);
> This is not arbitrary because all the stars (bits, transitive dependency
> versions) must "align" as defined by what Spring Boot 2.1 declares, and
> Spring Boot 2.1 is based on
> 
>  [6]
> Spring Data Lovelace/2.1.
> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
> 
>  [7]
> Apache Geode 1.6.
> 5. All SDG Lovelace/2.1.x versions will always be based on the latest
> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
> This ship has sailed.
>
> 
>
> 6. SBDG 1.2, when it reaches development (soon),will be based on Spring
> Boot 2.2
> 
>  [8],
> Spring Data (Geode) Moore
> 
>  [9]
> (or SDG 2.2
> 
>  [10]);
> This is also not arbitrary because Spring Boot 2.2 declares a dependency
> on
> 
>  [11]
> Spring Data Moore.  Again, the stars must align.
> 7. Spring Data Geode (SDG) Moore/2.2 is based on
> 
>  [12]
> Apache Geode 1.9.0.
> 8. As you can see, SDG Moore/2.2 is already in release candidates (i.e.
> RC2 or the 2nd release candidate), which means SDG cannot be rebased on
> 1.10 at this point.  The transitive dependency major.minor versions are now
> fixed for SD(G) Moore/2.2.
> 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g. 1.9.1
> up to  1.9.N where N is 0... infinity).
>
> Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11 or
> 1.whatever is in the next SD Release Trains, Neuman, or 2.3.  SDG can
> continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc
> until SDG Neuman/2.3 reaches it's first release candidate (RC) release, at
> which point the major.minor becomes fixed in that particular SD Release
> Train, until the next SD Release Train (Neuman.next).
>
> Make sense?
>
> So, it is the SDG version (along with Spring Boot core) that SBDG depends
> on that determines the version of Apache Geode that SBDG pulls in.
>
> Hope this helps!
>
> Regards,
> John
>
>
> [1]
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> [2] https://github.com/spring-projects/spring-boot-data-geode/releases
> [3]
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
> [4]
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12
> [5]
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10
> [6]
> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/sp

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

Sorry, corrections below...

On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:

> Stated slightly a different way...
>
> If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then
> it would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2
> (which is and can only be Geode 1.9 *at this point*) for which SBDG is
> also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 and
> therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As such,
> the stars would not align and it would cause issues (or unexpected
> surprises, possibly conflicts) for users of Spring Boot when also using
> SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9 due to
> the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
> suddenly (possibly) change the Geode version to 1.10.  That is definitively
> bad.
>
> Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
>
> SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
> available) which will pull in the latest version of Geode at that time
> (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC
> status.
>
> Cheers,
> John
>
>
>
>
> On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
>
>> For clarification...
>>
>> 1. SBDG 1.1 is the "*current*" development line (on
>> 
>> master
>> 
>>  [1]);
>> SBDG 1.2 is *not* yet in development.
>> 2. SBDG 1.1 is at RC1
>>  [2].
>> 3. SBDG 1.1 is based on Spring Boot 2.1
>> 
>>  [3]
>> and Spring Data (Geode) Lovelace
>> 
>>  [4]
>> (or SDG 2.1
>> 
>>  [5]);
>> This is not arbitrary because all the stars (bits, transitive dependency
>> versions) must "align" as defined by what Spring Boot 2.1 declares, and
>> Spring Boot 2.1 is based on
>> 
>>  [6]
>> Spring Data Lovelace/2.1.
>> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
>> 
>>  [7]
>> Apache Geode 1.6.
>> 5. All SDG Lovelace/2.1.x versions will always be based on the latest
>> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
>> This ship has sailed.
>>
>> 
>>
>> 6. SBDG 1.2, when it reaches development (soon),will be based on Spring
>> Boot 2.2
>> 
>>  [8],
>> Spring Data (Geode) Moore
>> 
>>  [9]
>> (or SDG 2.2
>> 
>>  [10]);
>> This is also not arbitrary because Spring Boot 2.2 declares a dependency
>> on
>> 
>>  [11]
>> Spring Data Moore.  Again, the stars must align.
>> 7. Spring Data Geode (SDG) Moore/2.2 is based on
>> 
>>  [12]
>> Apache Geode 1.9.0.
>> 8. As you can see, SDG Moore/2.2 is already in release candidates (i.e.
>> RC2 or the 2nd release candidate), which means SDG cannot be rebased on
>> 1.10 at this point.  The transitive dependency major.minor versions are now
>> fixed for SD(G) Moore/2.2.
>> 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g.
>> 1.9.1 up to  1.9.N where N is 0... infinity).
>>
>> Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11 or
>> 1.whatever is in the next SD Release Trains, Neuman, or 2.3.  SDG can
>> continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc
>> until SDG Neuman/2.3 reaches it's first release candidate (RC) release, at
>> which point the major.minor becomes fixed in that particular SD Release
>> Train, until the next SD Release Train (Neuman.next).
>>
>> Make sense?
>>
>> So, it is the SDG version (along with Spring Boot core) that SBDG depends
>> on that determines the version of Apache Geode that SBDG pulls in.
>>
>> Hope this helps!
>>
>> Regards,
>> John
>>
>>
>> [1]
>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
>> [2] https://github.com/spring-projects/spring-boot-data-geode/releases
>> [3]
>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
>> [4]
>> ht

Re: Draft of Apache Geode Quarterly Report (Aug 2019) for your review

[Dave Barnes]

Thanks for the suggestion, Anthony. I harvested the following subjects from
the Dev list archive based on number of entries, and weeding out a few
house-keeping topics.
Here's what we added to the report, which was submitted to the board this
afternoon:

  - Topics of discussion included:
- Pull request review requirements
- OQL method invocation security
- Lightweight RFC process
- Refactoring performance statistic structure
- Coding standards
- Criteria for admitting committers, PMC members

On Tue, Aug 13, 2019 at 11:58 AM Anthony Baker  wrote:

> I think you could call out a number of interesting discussions that
> happened on the dev list:
>
> - CFP process
> - Criteria for being a committer
> - etc
>
> Anthony
>
>
> > On Aug 12, 2019, at 4:26 PM, Dave Barnes  wrote:
> >
> > Thanks, Aaron - good catch.
> >
> > On Mon, Aug 12, 2019 at 4:09 PM Aaron Lindsey 
> wrote:
> >
> >> Kind of a small thing, but the Committer-to-PMC ratio seems more like
> 2:1
> >> based on the numbers of committers and PMC members below.
> >>
> >> - Aaron
> >>
> >>> On Aug 12, 2019, at 2:22 PM, Dave Barnes  wrote:
> >>>
> >>> Reformatted for more amenable viewing:
> >>>
> >>> ## Description:
> >>>
> >>> The mission of Apache Geode is the creation and maintenance of software
> >>> related
> >>>
> >>> to a data management platform that provides real-time, consistent
> access
> >> to
> >>>
> >>> data-intensive applications throughout widely distributed cloud
> >>> architectures.
> >>>
> >>>
> >>> ## Issues:
> >>>
> >>> There are no issues requiring board attention at this time.
> >>>
> >>>
> >>> ## Membership Data:
> >>>
> >>> Apache Geode was founded 2016-11-15 (3 years ago) There are currently
> 102
> >>>
> >>> committers and 50 PMC members in this project. The Committer-to-PMC
> >> ratio is
> >>>
> >>> roughly 7:4.
> >>>
> >>>
> >>> Community changes, past quarter:
> >>>
> >>> - No new PMC members. Last additions were Juan Ramos and Robert
> Houghton
> >> on
> >>>
> >>> 2019-02-20
> >>>
> >>> - Dale Emery was added as committer on 2019-06-19
> >>>
> >>> - Mark Hanson was added as committer on 2019-06-19
> >>>
> >>>
> >>> ## Project Activity:
> >>>
> >>> Release 1.10 is in progress.
> >>>
> >>>
> >>> An Apache Geode Summit is scheduled the day before the SpringOne
> Platform
> >>> 2019
> >>>
> >>> conference, on 7 October 2019, in Austin, TX. Several Geode
> contributors
> >>> will
> >>>
> >>> present talks and sessions aimed at a variety of levels.
> >>>
> >>>
> >>> ## Community Health:
> >>>
> >>> Mailing lists remain active and productive.
> >>>
> >>> - dev@geode.apache.org had a 13% increase in traffic in the past
> >> quarter
> >>>
> >>> (505 emails compared to 443)
> >>>
> >>>
> >>> JIRA tickets show that issues continue to be identified and resolved.
> >>>
> >>> - 289 issues opened in JIRA in the past quarter
> >>>
> >>> - 296 issues closed in   JIRA in the past quarter
> >>>
> >>> - 454 commits in the past quarter
> >>>
> >>>
> >>> The community is actively contributing to the Apache Geode code base:
> >>>
> >>> - 62 code contributors in the past quarter
> >>>
> >>> - 344 PRs opened on GitHub in the past quarter
> >>>
> >>> - 356 PRs closed on GitHub in the past quarter
> >>>
> >>> On Mon, Aug 12, 2019 at 2:10 PM Dave Barnes 
> wrote:
> >>>
>  Please review by Noon PDT, Tuesday, Aug 13. Thanks!
> 
>  ## Description:
> 
>  The mission of Apache Geode is the creation and maintenance of
> software
>  related
>  to a data management platform that provides real-time, consistent
> access
>  to
>  data-intensive applications throughout widely distributed cloud
>  architectures.
> 
>  ## Issues: There are no issues requiring board attention at this time.
> >> ##
>  Membership Data: Apache Geode was founded 2016-11-15 (3 years ago)
> There
>  are currently 102 committers and 50 PMC members in this project. The
>  Committer-to-PMC ratio is roughly 7:4. Community changes, past
> quarter:
> >> -
>  No new PMC members. Last additions were Juan Ramos and Robert Houghton
> >> on
>  2019-02-20 - Dale Emery was added as committer on 2019-06-19 - Mark
> >> Hanson
>  was added as committer on 2019-06-19 ## Project Activity: Release 1.10
> >> is
>  in progress. An Apache Geode Summit is scheduled the day before the
>  SpringOne Platform 2019 conference, on 7 October 2019, in Austin, TX.
>  Several Geode contributors will present talks and in traffic in the
> past
>  quarter (505 emails compared to 443) JIRA tickets show that issues
> >> continue
>  to be identified and resolved. - 289 issues opened in JIRA in the past
>  quarter - 296 issues closed in JIRA in the past quarter - 454 commits
> in
>  the past quarter The community is actively contributing to the Apache
>  Geode code base: - 62 code contributors in the past quarter - 344 PRs
>  opened on GitHub in the past quarter - 356 PRs closed on GitHub in the
>

Re: Failing LGTM Check

[Jacob Barrett]

LGTM confirmed this is a recent issue on their end that they are currently 
addressing.

https://discuss.lgtm.com/t/analysis-failed-in-github-pr-integration/2251

-Jake


> On Aug 13, 2019, at 1:48 PM, Aaron Lindsey  wrote:
> 
> My PR has a LGTM check that shows “Failing” on the PR and LGTM site, but the 
> LGTM logs say “Succeeded”:
> Failing PR check: https://github.com/apache/geode/pull/3913/checks 
> 
> Failing check on LGTM site: 
> https://lgtm.com/projects/g/apache/geode/rev/pr-f50cce2f02aa0f88f0d6beecbf236b29bc29683a
>  
> 
> LGTM logs with “Succeeded” message: 
> https://lgtm.com/projects/g/apache/geode/logs/rev/pr-f50cce2f02aa0f88f0d6beecbf236b29bc29683a/lang:java/stage:Preparing%20merge%20commit_6f1814d1f719cc06b13769c40a9d6d01f99f927c
>  
> 
> 
> How should I proceed with fixing this failing check?
> 
> - Aaron

Propose fix for 1.10 release: Prevent NPE in getLocalSize()

[Aaron Lindsey]

I’d like to propose including 
https://github.com/apache/geode/pull/3913/commits/6f1814d1f719cc06b13769c40a9d6d01f99f927c
 

 in the Geode 1.10 release.

This commit fixes an issue where a NullPointerException is thrown from 
PartitionedRegion.getLocalSize() when the statistics callback sampler is 
invoked before a PartitionedRegion is initialized.

- Aaron

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

[Udo Kohlmeyer]

@Aaron, is this an existing issue (i.e this was not introduced in a 
current refactor)?


If the answer is anything other that "This will make the system stop 
working", I would vote: -1


If this is an existing issue and has been around for a while, I think we 
hold off including this.


I think the boat has sailed on the inclusion of issues into the 1.10 
release. Sorry...


--Udo

On 8/13/19 4:58 PM, Aaron Lindsey wrote:

I’d like to propose including 
https://github.com/apache/geode/pull/3913/commits/6f1814d1f719cc06b13769c40a9d6d01f99f927c
 

 in the Geode 1.10 release.

This commit fixes an issue where a NullPointerException is thrown from 
PartitionedRegion.getLocalSize() when the statistics callback sampler is 
invoked before a PartitionedRegion is initialized.

- Aaron

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

[Dick Cavender]

Hi Aaron, thank you for bringing your request and concern.

Geode's release process dictates a time-based schedule to cut release
branches.  Once cut, the “critical fixes” rule does allow those to be
brought

to the release branch by proposal on the dev list.

If there is consensus from the Geode community that your proposed
change satisfies the “critical fixes” rule we can bring it to the
1.10.0

release branch. There are a number of issues that will likely bring in
other changes this week. Udo can still vote -1 and hope any future
Spring requests

won't be affected :^)


I'll be unavailable the rest of the week starting tomorrow so Dan will
assist with approved merges to 1.10 until Owen is back on Monday.

Regards

Dick Cavender


On Tue, Aug 13, 2019 at 5:32 PM Udo Kohlmeyer  wrote:

> @Aaron, is this an existing issue (i.e this was not introduced in a
> current refactor)?
>
> If the answer is anything other that "This will make the system stop
> working", I would vote: -1
>
> If this is an existing issue and has been around for a while, I think we
> hold off including this.
>
> I think the boat has sailed on the inclusion of issues into the 1.10
> release. Sorry...
>
> --Udo
>
> On 8/13/19 4:58 PM, Aaron Lindsey wrote:
> > I’d like to propose including
> https://github.com/apache/geode/pull/3913/commits/6f1814d1f719cc06b13769c40a9d6d01f99f927c
> <
> https://github.com/apache/geode/pull/3913/commits/6f1814d1f719cc06b13769c40a9d6d01f99f927c>
> in the Geode 1.10 release.
> >
> > This commit fixes an issue where a NullPointerException is thrown from
> PartitionedRegion.getLocalSize() when the statistics callback sampler is
> invoked before a PartitionedRegion is initialized.
> >
> > - Aaron
> >
> >
> >
>

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

[Anthony Baker]

Given that we’re trying to stabilize the release branch and this fix seems to 
*help* that I’m in favor of merging it.

Anthony


> On Aug 13, 2019, at 5:32 PM, Udo Kohlmeyer  wrote:
> 
> @Aaron, is this an existing issue (i.e this was not introduced in a current 
> refactor)?
> 
> If the answer is anything other that "This will make the system stop 
> working", I would vote: -1
> 
> If this is an existing issue and has been around for a while, I think we hold 
> off including this.
> 
> I think the boat has sailed on the inclusion of issues into the 1.10 release. 
> Sorry...
> 
> --Udo
> 
> On 8/13/19 4:58 PM, Aaron Lindsey wrote:
>> I’d like to propose including 
>> https://github.com/apache/geode/pull/3913/commits/6f1814d1f719cc06b13769c40a9d6d01f99f927c
>>  
>> 
>>  in the Geode 1.10 release.
>> 
>> This commit fixes an issue where a NullPointerException is thrown from 
>> PartitionedRegion.getLocalSize() when the statistics callback sampler is 
>> invoked before a PartitionedRegion is initialized.
>> 
>> - Aaron
>> 
>> 
>>