Re: Proposal to Include GEODE-7079 in 1.10.0

Thanks Owen!!. On Mon, Aug 19, 2019 at 3:44 PM Owen Nichols wrote: > There appears to be consensus that this is a critical fix. > > The following commit has been brought into release/1.10.0 < > https://github.com/apache/geode/tree/release/1.10.0> as the critical fix > for GEODE-7079

Re: Proposal to Include GEODE-7079 in 1.10.0

There appears to be consensus that this is a critical fix. The following commit has been brought into release/1.10.0 as the critical fix for GEODE-7079 : git cherry-pick -x

Re: Proposal to Include GEODE-7079 in 1.10.0

Hello team, Just following up on my proposal to include GEODE-7079 in release 1.10.0, I think there's enough consensus at this point (+1: 7, +0: 1), can we cherry pick commit *6f4bbbd [1]* into the release branch?. Best regards. [1]:

Re: Proposal to Include GEODE-7079 in 1.10.0

I'm changing my vote to +1 on this issue. The ONLY reason I'm changing my vote is to add to the cleanliness of the code of the release. I do 100% disagree with the continual scope creep that we have been incurring on this release branch. --Udo On 8/15/19 12:34 PM, Dan Smith wrote: +1 to

Re: Proposal to Include GEODE-7079 in 1.10.0

@Dan, not arguing that logs filling up with NPE's could bring a system down with limit disk space, or potentially swallowing important logs that could be helpful in root-causing issues... I'm merely raising the question on why this bug fix should receive priority inclusion. It has been around

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 to merging Juan's fix for GEODE-7079. I've seen systems taken down by rapidly filling up the logs in the past, this does seem to be a critical fix from the perspective of system stability. Also, this is the change, which doesn't seem particularly risky to me. - ConflationKey key =

Re: Proposal to Include GEODE-7079 in 1.10.0

Whilst I agree with "*finish* when we believe the quality of the release branch is sufficient", I disagree that we should have cut a branch and continue to patch that branch with non-critical fixes. i.e this issue has been around for a while and has no averse side effects. Issues like

Re: Proposal to Include GEODE-7079 in 1.10.0

In this specific case, how long has this issue been in the product? When did we first see it? That would give me a lot more context in gauging the “criticality” of this. Juan, can you share that information? To Udo’s point, with every change we check in, we add some risk of instability or at

Re: Proposal to Include GEODE-7079 in 1.10.0

While we can’t fix *all known bugs*, I think where we do have a fix for an important issue we should think hard about the cost of not including that in a release. IMO, the fixed time approach to releases means that we *start* the release effort (including stabilization and bug fixing if

Re: Proposal to Include GEODE-7079 in 1.10.0

Seems everyone is in favor or including a /*non-critical*/ fix to an already cut branch of the a potential release... Am I missing something? Why cut a release at all... just have a perpetual cycle of fixes added to develop and users can chose what nightly snapshot build they would want to

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 On Thu, Aug 15, 2019 at 10:15 AM Alexander Murmann wrote: > +1 > > Agreed to fixing this. It's impossible for a user to discover they hit an > edge case that we fail to support till they are in prod and restart. > > On Thu, Aug 15, 2019 at 10:09 AM Juan José Ramos > wrote: > > > Hello Udo,

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 Agreed to fixing this. It's impossible for a user to discover they hit an edge case that we fail to support till they are in prod and restart. On Thu, Aug 15, 2019 at 10:09 AM Juan José Ramos wrote: > Hello Udo, > > Even if it is an existing issue I'd still consider it critical for those >

Re: Proposal to Include GEODE-7079 in 1.10.0

Hello Udo, Even if it is an existing issue I'd still consider it critical for those cases on which there are unprocessed events on the persistent queue after a restart and the region takes long to recover... you can actually see millions of *NPEs* flooding the member's logs. My two cents anyway,

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 On Thu, Aug 15, 2019 at 9:54 AM John Blum wrote: > +1 > > On Thu, Aug 15, 2019 at 5:30 AM Ju@N wrote: > > > Hello team, > > > > I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in > release > > 1.10.0. > > Long story short: a *NullPointerException* can be continuously thrown

Re: Proposal to Include GEODE-7079 in 1.10.0

Juan, From your explanation, it seems this issue is existing and not critical. Could we possibly hold this for 1.11? --Udo On 8/15/19 5:29 AM, Ju@N wrote: Hello team, I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in release 1.10.0. Long story short: a

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 On Thu, Aug 15, 2019 at 5:30 AM Ju@N wrote: > Hello team, > > I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in release > 1.10.0. > Long story short: a *NullPointerException* can be continuously thrown > and flood the member's logs if a serial event processor (either >