Re: Regarding variable name 1.10.0 ordinal?

[Bruce Schuchardt]

The backward-compatibility serialization methods based on 
Version.methodSuffix already add underscores between the 
major/minor/release numbers.  I think it would be nice to rename all of 
the ordinals and versions to use the same convention, like 
GEODE_1_10_0_ORDINAL



On 2/19/19 2:42 PM, Sai Boorlagadda wrote:

I am in process of adding a new ordinal for 1.10.0 and see that currently
the variables are named as GEODE_XYZ for a release x.y.x (eg, private
static final byte GEODE_1100_ORDINAL = 105;)

Question is are there any side effects for naming it as GEODE_1100_ORDINAL
for 1.10.0?
Not sure if there is a better way of doing this.

Sai

Release Managers

[Jacob Barrett]

Release manager need to add the next version number to JIRA when they branch 
the release. Changes going into develop need to be marked finished with a 
version but may not be merged to the current release branch.

Also, after release isn’t the release branch supposed to be deleted? So what 
gives with release/1.7.0 and release/1.8.0?

-Jake

Re: Release Managers

[Bruce Schuchardt]

I would _really_ like to keep the release branches for historical 
purposes.  It's very useful to be able to look back and see what 
was/wasn't in a release when someone has a problem.  If we delete the 
branches we need some other way to record that information so that it's 
readily available.


On 2/20/19 8:41 AM, Jacob Barrett wrote:

Release manager need to add the next version number to JIRA when they branch 
the release. Changes going into develop need to be marked finished with a 
version but may not be merged to the current release branch.

Also, after release isn’t the release branch supposed to be deleted? So what 
gives with release/1.7.0 and release/1.8.0?

-Jake

Re: Release Managers

[Jacob Barrett]

> On Feb 20, 2019, at 8:58 AM, Bruce Schuchardt  wrote:
> 
> I would _really_ like to keep the release branches for historical purposes.  
> It's very useful to be able to look back and see what was/wasn't in a release 
> when someone has a problem.  If we delete the branches we need some other way 
> to record that information so that it's readily available

That is what the release tag is for.

Re: Release branch for Apache Geode 1.9.0 has been cut

[Jason Huynh]

Oh ok I thought I read that voting was going to start soon, so I thought
I'd raise a concern about the tickets not being fixed yet.

I meant this ticket https://issues.apache.org/jira/browse/GEODE-6359  This
seems like a bad thing to have in the product.  It looks like a possible
issue when processLeaveRequests.  I think the fix would be to just copy the
list or not log the list of members.



On Tue, Feb 19, 2019 at 5:35 PM Sai Boorlagadda 
wrote:

> GEODE-6404 can be cherry-picked when it is ready.
> The release branch is cut to avoid any risk of regression that
> can be introduced by new work being merged to develop.
>
> Do you mean GEODE-6369?
>
> On Tue, Feb 19, 2019 at 4:50 PM Jason Huynh  wrote:
>
> > Correction, GEODE-6359 and GEODE-6404.
> >
> > On Tue, Feb 19, 2019 at 4:49 PM Jason Huynh  wrote:
> >
> > > I still haven't gotten GEODE-6404 in... I assumed that the tickets from
> > > the last thread were going to make it into this release?
> > >
> > > Also I think GEODE-6539 should be fixed, it looks like an NPE that
> occurs
> > > when we process leave requests.
> > >
> > >
> > >
> > > On Tue, Feb 19, 2019 at 2:25 PM Sai Boorlagadda <
> > sai.boorlaga...@gmail.com>
> > > wrote:
> > >
> > >> My earlier release branch has created as 'release/1.9' without the
> patch
> > >> number in semver.
> > >> So I have re-created a new release branch 'release/1.9.0'.
> > >>
> > >> I will go ahead delete the unwanted branch 'release/1.9'
> > >>
> > >> Sai
> > >> On Tue, Feb 19, 2019 at 2:17 PM Sai Boorlagadda <
> > >> sai.boorlaga...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hello Everyone,
> > >> >
> > >> > As discussed in my earlier email I have created a new release branch
> > >> for Apache Geode 1.9.0 - "release/1.9"
> > >> >
> > >> > Please do review and raise any concern with the release branch.
> > >> > If no concerns are raised, we will start with the voting for the
> > >> release candidate soon.
> > >> >
> > >> > Regards
> > >> > Sai
> > >> >
> > >> >
> > >>
> > >
> >
>

Re: Release Managers

[Bruce Schuchardt]

great - that works for me

On 2/20/19 9:05 AM, Jacob Barrett wrote:



On Feb 20, 2019, at 8:58 AM, Bruce Schuchardt  wrote:

I would _really_ like to keep the release branches for historical purposes.  
It's very useful to be able to look back and see what was/wasn't in a release 
when someone has a problem.  If we delete the branches we need some other way 
to record that information so that it's readily available

That is what the release tag is for.

Re: Release branch for Apache Geode 1.9.0 has been cut

[Alexander Murmann]

>
> Oh ok I thought I read that voting was going to start soon
>
Are you referring to the RC vote? Per the previous discussed release
schedule and the wiki
, the
actual release shouldn't happen till March 1st.

On Wed, Feb 20, 2019 at 9:08 AM Jason Huynh  wrote:

> Oh ok I thought I read that voting was going to start soon, so I thought
> I'd raise a concern about the tickets not being fixed yet.
>
> I meant this ticket https://issues.apache.org/jira/browse/GEODE-6359  This
> seems like a bad thing to have in the product.  It looks like a possible
> issue when processLeaveRequests.  I think the fix would be to just copy the
> list or not log the list of members.
>
>
>
> On Tue, Feb 19, 2019 at 5:35 PM Sai Boorlagadda  >
> wrote:
>
> > GEODE-6404 can be cherry-picked when it is ready.
> > The release branch is cut to avoid any risk of regression that
> > can be introduced by new work being merged to develop.
> >
> > Do you mean GEODE-6369?
> >
> > On Tue, Feb 19, 2019 at 4:50 PM Jason Huynh  wrote:
> >
> > > Correction, GEODE-6359 and GEODE-6404.
> > >
> > > On Tue, Feb 19, 2019 at 4:49 PM Jason Huynh  wrote:
> > >
> > > > I still haven't gotten GEODE-6404 in... I assumed that the tickets
> from
> > > > the last thread were going to make it into this release?
> > > >
> > > > Also I think GEODE-6539 should be fixed, it looks like an NPE that
> > occurs
> > > > when we process leave requests.
> > > >
> > > >
> > > >
> > > > On Tue, Feb 19, 2019 at 2:25 PM Sai Boorlagadda <
> > > sai.boorlaga...@gmail.com>
> > > > wrote:
> > > >
> > > >> My earlier release branch has created as 'release/1.9' without the
> > patch
> > > >> number in semver.
> > > >> So I have re-created a new release branch 'release/1.9.0'.
> > > >>
> > > >> I will go ahead delete the unwanted branch 'release/1.9'
> > > >>
> > > >> Sai
> > > >> On Tue, Feb 19, 2019 at 2:17 PM Sai Boorlagadda <
> > > >> sai.boorlaga...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hello Everyone,
> > > >> >
> > > >> > As discussed in my earlier email I have created a new release
> branch
> > > >> for Apache Geode 1.9.0 - "release/1.9"
> > > >> >
> > > >> > Please do review and raise any concern with the release branch.
> > > >> > If no concerns are raised, we will start with the voting for the
> > > >> release candidate soon.
> > > >> >
> > > >> > Regards
> > > >> > Sai
> > > >> >
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: Release Managers

[Sai Boorlagadda]

Do we need to create an infra ticket to create a new release?
I don't seem to have permissions to create releases in Jira.

On Wed, Feb 20, 2019 at 8:42 AM Jacob Barrett  wrote:

> Release manager need to add the next version number to JIRA when they
> branch the release. Changes going into develop need to be marked finished
> with a version but may not be merged to the current release branch.
>
> Also, after release isn’t the release branch supposed to be deleted? So
> what gives with release/1.7.0 and release/1.8.0?
>
> -Jake
>
>

feature/GEODE-6389b -> release/1.9.0

[Bruce Schuchardt]

I'm planning to merge the fix for 6389 to release/1.9.0 after it passes 
precheckin/review.


This fix is essential unless we back out the changes for GEODE-2113

Re: Bug Numbers and Trac Numbers in comments

[Ken Howe]

+1 - What Jake said. 

> On Feb 19, 2019, at 5:21 PM, Jacob Barrett  wrote:
> 
> Comments that don’t provide meaningful context beyond what is already 
> expressed in the code should be removed. A number to a system that the 
> general public can’t access is not meaningful. Delete or replace with 
> meaningful comment.
> 
> -jake
> 
> 
>> On Feb 19, 2019, at 1:41 PM, Michael Oleske  wrote:
>> 
>> Hey Geode Dev Friends!
>> 
>> I was reviewing a PR (this one https://github.com/apache/geode/pull/3197)
>> and made a note that maybe we should remove comments that make references
>> to bug and trac numbers that people cannot reach (like me for one).  Kirk
>> mentioned that some people (like him) have access to those bugs and have
>> proven helpful for some history.  So there is this balance between noise
>> (people who cannot access those old issues) and getting context (people who
>> can access those issues).
>> 
>> So I guess my point is to start a discussion on what a path forward might
>> be (if any)?  My opinion is that they are noise and we should remove them.
>> If someone has access to the original issue, then making sure there is a
>> test case covering it should be done.  Then it makes even more sense to me
>> to remove the comment.
>> 
>> -michael

Re: Bug Numbers and Trac Numbers in comments

[Kirk Lund]

Well, the problem is that different people disagree on what's "meaningful"
in this context. For example:

See PersistentPartitionHangsDuringRestartRegressionTest.java

*  /***
*   * RegressionTest for bug 42226. *
*   * 1. Member A has the bucket *
*   * 2. Member B starts creating the bucket. It tells member A that it
hosts the bucket *
*   * 3. Member A crashes *
*   * 4. Member B destroys the bucket and throws a partition offline
exception, because it wasn't*
*   * able to complete initialization. *
*   * 5. Member A recovers, and gets stuck waiting for member B.*
*   **
*   * *
*   * TRAC 42226: recycled VM hangs during re-start while waiting for
Partition to come online (after*
*   * Controller VM sees unexpected PartitionOffLineException while doing
ops)*
*   */*
*  @Test*
*  public void doesNotWaitForPreviousInstanceOfOnlineServer() throws
Exception {*

I personally would NOT remove the references to "42226" from the above, and
here's why:
1) The javadoc clearly states the what and how of this bug
2) The 2nd paragraph includes the full summary from the old TRAC ticket
3) Quite a few people working on Geode do have access to TRAC which means
anyone in the community can request us to go dig up further history about
this bug to share

If we systematically delete all TRAC #s from javadocs and comments then
community developers will lose that opportunity. While it's true that most
of the time most developers will probably never need or want that history,
I would not say it's never going to be valuable.

When I'm working on code that references old bugs (especially regression
tests like the one above), I frequently pull up TRAC and read about the
bug. I also tend to pull up the old pre-Apache git repo and read through
old commit messages. Maybe I'm the only one who does this.

Despite my point of view, I don't feel very strongly about it. If you guys
really think that the TRAC #s distract or confuse you too much and you
can't foresee the need to ask someone to pull up history on a ticket, then
you should submit a PR to "remove all TRAC #s" from the code base. I won't
disapprove it -- I can always look at older revisions of files like
PersistentPartitionHangsDuringRestartRegressionTest to find the old TRAC #.
I previously submitted PRs to rename all test classes and test methods from
names like test42226 to meaningful names so I support the overall intent.

On Tue, Feb 19, 2019 at 5:21 PM Jacob Barrett  wrote:

> Comments that don’t provide meaningful context beyond what is already
> expressed in the code should be removed. A number to a system that the
> general public can’t access is not meaningful. Delete or replace with
> meaningful comment.
>
> -jake
>
>
> > On Feb 19, 2019, at 1:41 PM, Michael Oleske  wrote:
> >
> > Hey Geode Dev Friends!
> >
> > I was reviewing a PR (this one https://github.com/apache/geode/pull/3197
> )
> > and made a note that maybe we should remove comments that make references
> > to bug and trac numbers that people cannot reach (like me for one).  Kirk
> > mentioned that some people (like him) have access to those bugs and have
> > proven helpful for some history.  So there is this balance between noise
> > (people who cannot access those old issues) and getting context (people
> who
> > can access those issues).
> >
> > So I guess my point is to start a discussion on what a path forward might
> > be (if any)?  My opinion is that they are noise and we should remove
> them.
> > If someone has access to the original issue, then making sure there is a
> > test case covering it should be done.  Then it makes even more sense to
> me
> > to remove the comment.
> >
> > -michael
>

Re: Release Managers

[Dan Smith]

I added a 1.10.0 release to JIRA.

-Dan

On Wed, Feb 20, 2019 at 9:29 AM Sai Boorlagadda 
wrote:

> Do we need to create an infra ticket to create a new release?
> I don't seem to have permissions to create releases in Jira.
>
> On Wed, Feb 20, 2019 at 8:42 AM Jacob Barrett  wrote:
>
> > Release manager need to add the next version number to JIRA when they
> > branch the release. Changes going into develop need to be marked finished
> > with a version but may not be merged to the current release branch.
> >
> > Also, after release isn’t the release branch supposed to be deleted? So
> > what gives with release/1.7.0 and release/1.8.0?
> >
> > -Jake
> >
> >
>

Re: Bug Numbers and Trac Numbers in comments

[Alexander Murmann]

I think it's important that we enable everyone in the community to be
equally successful and on top of that do NOT rely on non-Apache resources.
If we find value in Trac numbers, we should either find a way to make them
accessible to everyone or update the comment so that there is no value in
knowing the number.

In general, I avoid references in the code to anything outside the code
base as much as possible. Anything that's checked into the repo gets
versioned together and I don't have to worry about aligning versions of
what's in the code with potential versions of the outside resource. So my
vote is for augmenting the comment. Maybe we can do even better and make
the code or test self-explanatory enough to need even fewer comments?

On Wed, Feb 20, 2019 at 10:23 AM Kirk Lund  wrote:

> Well, the problem is that different people disagree on what's "meaningful"
> in this context. For example:
>
> See PersistentPartitionHangsDuringRestartRegressionTest.java
>
> *  /***
> *   * RegressionTest for bug 42226. *
> *   * 1. Member A has the bucket *
> *   * 2. Member B starts creating the bucket. It tells member A that it
> hosts the bucket *
> *   * 3. Member A crashes *
> *   * 4. Member B destroys the bucket and throws a partition offline
> exception, because it wasn't*
> *   * able to complete initialization. *
> *   * 5. Member A recovers, and gets stuck waiting for member B.*
> *   **
> *   * *
> *   * TRAC 42226: recycled VM hangs during re-start while waiting for
> Partition to come online (after*
> *   * Controller VM sees unexpected PartitionOffLineException while doing
> ops)*
> *   */*
> *  @Test*
> *  public void doesNotWaitForPreviousInstanceOfOnlineServer() throws
> Exception {*
>
> I personally would NOT remove the references to "42226" from the above, and
> here's why:
> 1) The javadoc clearly states the what and how of this bug
> 2) The 2nd paragraph includes the full summary from the old TRAC ticket
> 3) Quite a few people working on Geode do have access to TRAC which means
> anyone in the community can request us to go dig up further history about
> this bug to share
>
> If we systematically delete all TRAC #s from javadocs and comments then
> community developers will lose that opportunity. While it's true that most
> of the time most developers will probably never need or want that history,
> I would not say it's never going to be valuable.
>
> When I'm working on code that references old bugs (especially regression
> tests like the one above), I frequently pull up TRAC and read about the
> bug. I also tend to pull up the old pre-Apache git repo and read through
> old commit messages. Maybe I'm the only one who does this.
>
> Despite my point of view, I don't feel very strongly about it. If you guys
> really think that the TRAC #s distract or confuse you too much and you
> can't foresee the need to ask someone to pull up history on a ticket, then
> you should submit a PR to "remove all TRAC #s" from the code base. I won't
> disapprove it -- I can always look at older revisions of files like
> PersistentPartitionHangsDuringRestartRegressionTest to find the old TRAC #.
> I previously submitted PRs to rename all test classes and test methods from
> names like test42226 to meaningful names so I support the overall intent.
>
> On Tue, Feb 19, 2019 at 5:21 PM Jacob Barrett  wrote:
>
> > Comments that don’t provide meaningful context beyond what is already
> > expressed in the code should be removed. A number to a system that the
> > general public can’t access is not meaningful. Delete or replace with
> > meaningful comment.
> >
> > -jake
> >
> >
> > > On Feb 19, 2019, at 1:41 PM, Michael Oleske 
> wrote:
> > >
> > > Hey Geode Dev Friends!
> > >
> > > I was reviewing a PR (this one
> https://github.com/apache/geode/pull/3197
> > )
> > > and made a note that maybe we should remove comments that make
> references
> > > to bug and trac numbers that people cannot reach (like me for one).
> Kirk
> > > mentioned that some people (like him) have access to those bugs and
> have
> > > proven helpful for some history.  So there is this balance between
> noise
> > > (people who cannot access those old issues) and getting context (people
> > who
> > > can access those issues).
> > >
> > > So I guess my point is to start a discussion on what a path forward
> might
> > > be (if any)?  My opinion is that they are noise and we should remove
> > them.
> > > If someone has access to the original issue, then making sure there is
> a
> > > test case covering it should be done.  Then it makes even more sense to
> > me
> > > to remove the comment.
> > >
> > > -michael
> >
>

Merging GEODE-6424 into release/1.9.0

[Jacob Barrett]

Anyone have issue with merging https://issues.apache.org/jira/browse/GEODE-6424 
 into release/1.9.0? 

Without it we will have to wait for the next release before we can have 
meaningful baselines for function and query benchmarks. Without this fix 
baselines will continue to vary by as much as 45% making them useless.

It’s also a big performance boost. Concurrent local cache gets see about a 50% 
bump in throughput due to reduced contention for stats, even with timed stats 
enabled. Other operations haven’t been benchmarked but should see similar 
improvements where stats were the bottleneck.

-Jake

Re: Merging GEODE-6424 into release/1.9.0

[Owen Nichols]

My vote: Let’s get this into 1.9

On Wed, Feb 20, 2019 at 12:25 PM Jacob Barrett  wrote:

> Anyone have issue with merging
> https://issues.apache.org/jira/browse/GEODE-6424 <
> https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0?
>
> Without it we will have to wait for the next release before we can have
> meaningful baselines for function and query benchmarks. Without this fix
> baselines will continue to vary by as much as 45% making them useless.
>
> It’s also a big performance boost. Concurrent local cache gets see about a
> 50% bump in throughput due to reduced contention for stats, even with timed
> stats enabled. Other operations haven’t been benchmarked but should see
> similar improvements where stats were the bottleneck.
>
> -Jake
>
>

Re: Merging GEODE-6424 into release/1.9.0

[Dan Smith]

+1

On Wed, Feb 20, 2019 at 12:24 PM Jacob Barrett  wrote:

> Anyone have issue with merging
> https://issues.apache.org/jira/browse/GEODE-6424 <
> https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0?
>
> Without it we will have to wait for the next release before we can have
> meaningful baselines for function and query benchmarks. Without this fix
> baselines will continue to vary by as much as 45% making them useless.
>
> It’s also a big performance boost. Concurrent local cache gets see about a
> 50% bump in throughput due to reduced contention for stats, even with timed
> stats enabled. Other operations haven’t been benchmarked but should see
> similar improvements where stats were the bottleneck.
>
> -Jake
>
>

Re: Merging GEODE-6424 into release/1.9.0

[Udo Kohlmeyer]

+1, Go,Go,GO!!

On 2/20/19 12:24, Jacob Barrett wrote:

Anyone have issue with merging https://issues.apache.org/jira/browse/GEODE-6424 
 into release/1.9.0?

Without it we will have to wait for the next release before we can have 
meaningful baselines for function and query benchmarks. Without this fix 
baselines will continue to vary by as much as 45% making them useless.

It’s also a big performance boost. Concurrent local cache gets see about a 50% 
bump in throughput due to reduced contention for stats, even with timed stats 
enabled. Other operations haven’t been benchmarked but should see similar 
improvements where stats were the bottleneck.

-Jake

Re: Bug Numbers and Trac Numbers in comments

[Bruce Schuchardt]

+1 We shouldn't even reference Apache JIRA tickets.  References to 
outside things like Trac tickets, JIRA tickets or even commit SHAs 
become outdated over time.


On 2/20/19 11:28 AM, Alexander Murmann wrote:

I think it's important that we enable everyone in the community to be
equally successful and on top of that do NOT rely on non-Apache resources.
If we find value in Trac numbers, we should either find a way to make them
accessible to everyone or update the comment so that there is no value in
knowing the number.

In general, I avoid references in the code to anything outside the code
base as much as possible. Anything that's checked into the repo gets
versioned together and I don't have to worry about aligning versions of
what's in the code with potential versions of the outside resource. So my
vote is for augmenting the comment. Maybe we can do even better and make
the code or test self-explanatory enough to need even fewer comments?

On Wed, Feb 20, 2019 at 10:23 AM Kirk Lund  wrote:


Well, the problem is that different people disagree on what's "meaningful"
in this context. For example:

See PersistentPartitionHangsDuringRestartRegressionTest.java

*  /***
*   * RegressionTest for bug 42226. *
*   * 1. Member A has the bucket *
*   * 2. Member B starts creating the bucket. It tells member A that it
hosts the bucket *
*   * 3. Member A crashes *
*   * 4. Member B destroys the bucket and throws a partition offline
exception, because it wasn't*
*   * able to complete initialization. *
*   * 5. Member A recovers, and gets stuck waiting for member B.*
*   **
*   * *
*   * TRAC 42226: recycled VM hangs during re-start while waiting for
Partition to come online (after*
*   * Controller VM sees unexpected PartitionOffLineException while doing
ops)*
*   */*
*  @Test*
*  public void doesNotWaitForPreviousInstanceOfOnlineServer() throws
Exception {*

I personally would NOT remove the references to "42226" from the above, and
here's why:
1) The javadoc clearly states the what and how of this bug
2) The 2nd paragraph includes the full summary from the old TRAC ticket
3) Quite a few people working on Geode do have access to TRAC which means
anyone in the community can request us to go dig up further history about
this bug to share

If we systematically delete all TRAC #s from javadocs and comments then
community developers will lose that opportunity. While it's true that most
of the time most developers will probably never need or want that history,
I would not say it's never going to be valuable.

When I'm working on code that references old bugs (especially regression
tests like the one above), I frequently pull up TRAC and read about the
bug. I also tend to pull up the old pre-Apache git repo and read through
old commit messages. Maybe I'm the only one who does this.

Despite my point of view, I don't feel very strongly about it. If you guys
really think that the TRAC #s distract or confuse you too much and you
can't foresee the need to ask someone to pull up history on a ticket, then
you should submit a PR to "remove all TRAC #s" from the code base. I won't
disapprove it -- I can always look at older revisions of files like
PersistentPartitionHangsDuringRestartRegressionTest to find the old TRAC #.
I previously submitted PRs to rename all test classes and test methods from
names like test42226 to meaningful names so I support the overall intent.

On Tue, Feb 19, 2019 at 5:21 PM Jacob Barrett  wrote:


Comments that don’t provide meaningful context beyond what is already
expressed in the code should be removed. A number to a system that the
general public can’t access is not meaningful. Delete or replace with
meaningful comment.

-jake



On Feb 19, 2019, at 1:41 PM, Michael Oleske 

wrote:

Hey Geode Dev Friends!

I was reviewing a PR (this one

https://github.com/apache/geode/pull/3197

)

and made a note that maybe we should remove comments that make

references

to bug and trac numbers that people cannot reach (like me for one).

Kirk

mentioned that some people (like him) have access to those bugs and

have

proven helpful for some history.  So there is this balance between

noise

(people who cannot access those old issues) and getting context (people

who

can access those issues).

So I guess my point is to start a discussion on what a path forward

might

be (if any)?  My opinion is that they are noise and we should remove

them.

If someone has access to the original issue, then making sure there is

a

test case covering it should be done.  Then it makes even more sense to

me

to remove the comment.

-michael

Re: Merging GEODE-6424 into release/1.9.0

[Jacob Barrett]

Done!

> On Feb 20, 2019, at 1:22 PM, Udo Kohlmeyer  wrote:
> 
> +1, Go,Go,GO!!
> 
>> On 2/20/19 12:24, Jacob Barrett wrote:
>> Anyone have issue with merging 
>> https://issues.apache.org/jira/browse/GEODE-6424 
>>  into release/1.9.0?
>> 
>> Without it we will have to wait for the next release before we can have 
>> meaningful baselines for function and query benchmarks. Without this fix 
>> baselines will continue to vary by as much as 45% making them useless.
>> 
>> It’s also a big performance boost. Concurrent local cache gets see about a 
>> 50% bump in throughput due to reduced contention for stats, even with timed 
>> stats enabled. Other operations haven’t been benchmarked but should see 
>> similar improvements where stats were the bottleneck.
>> 
>> -Jake
>> 
>> 

Re: Merging GEODE-6424 into release/1.9.0

[Sai Boorlagadda]

Jake,

release branch build seems broken due to spotless changes.

https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main

Sai

On Wed, Feb 20, 2019 at 2:59 PM Jacob Barrett  wrote:

> Done!
>
> > On Feb 20, 2019, at 1:22 PM, Udo Kohlmeyer  wrote:
> >
> > +1, Go,Go,GO!!
> >
> >> On 2/20/19 12:24, Jacob Barrett wrote:
> >> Anyone have issue with merging
> https://issues.apache.org/jira/browse/GEODE-6424 <
> https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0?
> >>
> >> Without it we will have to wait for the next release before we can have
> meaningful baselines for function and query benchmarks. Without this fix
> baselines will continue to vary by as much as 45% making them useless.
> >>
> >> It’s also a big performance boost. Concurrent local cache gets see
> about a 50% bump in throughput due to reduced contention for stats, even
> with timed stats enabled. Other operations haven’t been benchmarked but
> should see similar improvements where stats were the bottleneck.
> >>
> >> -Jake
> >>
> >>
>

Re: Merging GEODE-6424 into release/1.9.0

[Jacob Barrett]

My bad! Sorry!

> On Feb 20, 2019, at 3:22 PM, Sai Boorlagadda  
> wrote:
> 
> Jake,
> 
> release branch build seems broken due to spotless changes.
> 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main
> 
> Sai
> 
>> On Wed, Feb 20, 2019 at 2:59 PM Jacob Barrett  wrote:
>> 
>> Done!
>> 
>>> On Feb 20, 2019, at 1:22 PM, Udo Kohlmeyer  wrote:
>>> 
>>> +1, Go,Go,GO!!
>>> 
 On 2/20/19 12:24, Jacob Barrett wrote:
 Anyone have issue with merging
>> https://issues.apache.org/jira/browse/GEODE-6424 <
>> https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0?
 
 Without it we will have to wait for the next release before we can have
>> meaningful baselines for function and query benchmarks. Without this fix
>> baselines will continue to vary by as much as 45% making them useless.
 
 It’s also a big performance boost. Concurrent local cache gets see
>> about a 50% bump in throughput due to reduced contention for stats, even
>> with timed stats enabled. Other operations haven’t been benchmarked but
>> should see similar improvements where stats were the bottleneck.
 
 -Jake
 
 
>> 

Re: Geode 1.9 Release Manager

[Patrick Rhomberg]

I would love for GEODE-6399 / PR #3190 to be included in this release.
This PR resolves the earlier issues we had delegating dependencies to the
geode-all-bom BOM and massively reduces the POMs for each module we publish.

As it is, the published POMs are functional, and I understand that such
things are rarely human-inspected, but given that we haven't introduced the
 into our maven artifacts yet, I'd just as soon have
it done right when we do.

Not really a show-stopping issue, but it does involve our forward-facing
artifacts.

On Tue, Feb 19, 2019 at 2:20 PM Sai Boorlagadda 
wrote:

> Thanks Bruce. I will chery-pick this commit onto the new release branch.
>
> On Tue, Feb 19, 2019 at 1:06 PM Bruce Schuchardt 
> wrote:
>
> > The fix for Geode-6369 has been pushed to develop.  This needs to go in
> > the 1.9 release as it fixes some serious issues in auto-reconnect
> > including a distributed deadlock.
> >
> > On 2/15/19 2:15 PM, Sai Boorlagadda wrote:
> > > There are about 8[1] issues in JIRA that are in
> > open/in-progress/re-opened
> > > status for 1.9.0.
> > > Can I request all the devs to reflect JIRA with current status?
> > >
> > > [1]
> > >
> >
> https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
> > >
> > > Sai
> > >
> > > On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda <
> > sai.boorlaga...@gmail.com>
> > > wrote:
> > >
> > >> Thanks Dave. I keep a note to include Geode Native.
> > >>
> > >> As we are including only a source release for Geode Native
> > >> do we need to create a release branch? Or just tag it?
> > >>
> > >> Though we will eventually be tagging Geode & Geode Examples repos.
> > >> So until it gets released I think as a place holder I can go ahead
> still
> > >> create a release branch for Geode Native?
> > >>
> > >> Sai
> > >>
> > >>
> > >> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes 
> wrote:
> > >>
> > >>> Sai,
> > >>> The Geode 1.8 release included (for the first time) a source snapshot
> > of
> > >>> the geode-native repo.
> > >>> As far as I know, the same treatment would be in order for v1.9.
> > >>>
> > >>>
> > >>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt <
> > bschucha...@pivotal.io>
> > >>> wrote:
> > >>>
> >  I would like to get GEODE-6369 into the next release but that can be
> >  done in a cherry-pick after I finish testing.  The changes are in in
> >  discovery, joining the cluster and in failure detection so they've
> >  needed extensive testing.
> > 
> >  On 2/15/19 7:53 AM, Sai Boorlagadda wrote:
> > > I am planning to cut the1.9 release branch today after merging this
> > > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> > >
> > > Is there anything other than that I should be aware of?
> > >
> > > Here is the list of issues that were requested to be included into
> > >>> 1.9.
> > > If there is any plan to merge any of these today let me know and
> > > I can cut the branch after that.
> > >
> > > GEODE-6334 - CachePerfStats operation count stats may wrap to
> > negative
> > > values
> > >
> > > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative
> > >>> value
> > > GEODE-6369 - Cache-creation failure after a successful
> auto-reconnect
> > > causes subsequent NPE
> > >
> > > GEODE-6391 - Event IDs must be included in the PartitioneRegion
> > >>> messages
> > > GEODE-6404 - review use of computeIfAbsent across the code base
> > >
> > >
> > > (experimental and dropped)
> > >
> > > GEODE-6393 - Replace synchronization lock with AtomicReference for
> > > InternalLocator
> > >
> > >
> > > -
> > >
> > > Sai
> > >
> > > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> >  sai.boorlaga...@gmail.com>
> > > wrote:
> > >
> > >> I didn't mean blocking a release but the release process
> (including
> > >> cutting the branch).
> > >>
> > >>
> > >> I thought there was a consensus about strictly cutting a
> > >>
> > >> branch[1] with our new fixed minor release cadence and
> > >>
> > >> only allow critical fixes.
> > >>
> > >>
> > >> I assumed that any critical fixes that are allowed onto the
> > >>
> > >> release branch are the ones that are identified on the branch
> > >>
> > >> after it is cut and not the ones that are already known.
> > >>
> > >>
> > >> Correct me if my understanding is wrong.
> > >>
> > >>
> > >> [1]
> > >>
> > >>>
> >
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> > >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag 
> > >>> wrote:
> > >>> I could not find any DISCUSS mails about not blocking a release.
> I
> > >>> may
> >  be
> > >>> wrong, I apologize f