Re: [DISCUSS] Predictable minor release cadence

[Anthony Baker]

I’ve been advocating for a fixed release schedule for a long time.  3 months 
seems like a good rate given the release overhead.

+1 on cutting the next release branch in November and shooting for an early 
December v1.8.0 release.

Anthony


> On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda  wrote:
> 
> I agree with Robert that we should release based on features that go in.
> 
> I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> These tools were evolving rapidly in the last couple of years and frequent
> releases would be good for a growing community.
> 
> Should we do a patch release every few months to include bug fixes?
> 
> Sai
> 
> 
> On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  wrote:
> 
>> I have found it refreshing that the geode released cadence has been based
>> on features being done,  rather than a set schedule.
>> 
>> I come from an environment where we had quarterly releases and monthly
>> patches to all supported previous releases, and I can tell you that it
>> became a grind. That being said, within that release cadence a one-month
>> ramp for bug fixes on the release branch was almost always sufficient.
>> 
>> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
>> 
>>> +1 for scheduled releases and cutting the branch one month prior to
>>> release. Given the time it took to fully root out, classify, and solve
>>> issues with this 1.7 release, I think a month is the right amount of time
>>> between cutting the branch and releasing.  If it ends up being too much
>> or
>>> too little, we can always adjust.
>>> 
>>> I don’t feel strongly about the release cadence, but I generally favor
>> more
>>> frequent releases if possible (3 month over 6 month).  That way new
>>> features can get into the hands of users sooner, assuming the feature
>> takes
>>> less than 3 months to complete.  Again, we can adjust the cadence if
>>> necessary if it is too frequent or infrequent.
>>> 
>>> Ryan
>>> 
>>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
>>> wrote:
>>> 
 Anil, releasing every 3 months should give us 3 months of dev work.
>> Don't
 forget that there will be one month during which the next release is
 already cut, but the vast majority of the work is going to the release
 after that. So while we cut 1.7 one month ago and release 1.7 today, we
 already have one month of work on develop again. It's not going to work
>>> out
 for this first release though, due to my suggestion to cut a month
>> early
>>> to
 avoid holidays. If I recall correctly our past problem was that it took
 longer to iron out issue on the release branch than expected. The
>>> solution
 to that would be to cut the release even earlier, but 1 month feels
>> very
 generous.
 
 On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
 wrote:
 
> If I remember from earlier discussion; the plan was to deliver a
>>> release
> once 3 months. But from the past release history we had difficulty in
> achieving that, either the features are not completely ready or the
> bug-fixes have taken more time. We need verify what is right for
>> Apache
> Geode, 3, 4 or 6 months; and there is any community dev/activity that
> depends on Geode release.
> My vote will be for 4 or 6 months, as it provides at least 3+ month
>> for
 dev
> activity and 1 month for QA.
> 
> -Anil.
> 
> 
> On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> 
>> +1 I definitely like the idea of scheduled releases.
>> 
>> I wonder if cutting the release branch a month ahead of time is
 overkill,
>> but I guess we do seem to keep finding issues after the branch is
>>> cut.
>> 
>> -Dan
>> 
>> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
>>> amurm...@pivotal.io>
>> wrote:
>> 
>>> Hi everyone,
>>> 
>>> I want to propose shipping Geode on a regular cadence. My
>> concrete
>> proposal
>>> is to ship Geode every 3 months on the first weekday. To make
>> sure
>>> we
> hit
>>> that date we would cut the release 1 months prior to that day.
>>> 
>>> *Why?*
>>> Knowing on what day the release will get cut and on what day we
>>> ship
>> allows
>>> community members to plan their contributions. If I want my
>> feature
 to
> be
>>> in the next release I know by when I need to have it merged to
 develop
>> and
>>> can plan accordingly. As a user who is waiting for a particular
 feature
>> or
>>> fix that's already on develop, I know when to expect the release
>>> that
>>> includes this work and again, can plan accordingly.
>>> 
>>> This makes working and using Apache Geode more predictable which
 makes
>> all
>>> our lives less stressful. To make this work, it's important to be
> strict
>>> about cutting the release branch on the set date and only allow
> critical
>>> fixes after the release ha

Re: [DISCUSS] Predictable minor release cadence

[Alexander Murmann]

Robert and Sai, I think either release process can be stressful if your
team doesn't understand that there is no faster button, but that the only
lever is to cut scope (you can also compromise quality, but let's not do
that).
In either scenario there can be release pressure. To me the biggest
difference is that with a fixed schedule I at least have a good chance to
see sooner that I need to cut scope to catch the next train. Without a
fixed schedule, I suddenly might find myself in the situation that everyone
else is ready to ship and is waiting on me and getting impatient. I might
have not even been able to see that coming unless I am constantly checking
with everyone else to find out when they think they might be ready to ship.

To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a
massively growing community 😉

On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:

> I’ve been advocating for a fixed release schedule for a long time.  3
> months seems like a good rate given the release overhead.
>
> +1 on cutting the next release branch in November and shooting for an
> early December v1.8.0 release.
>
> Anthony
>
>
> > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda 
> wrote:
> >
> > I agree with Robert that we should release based on features that go in.
> >
> > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > These tools were evolving rapidly in the last couple of years and
> frequent
> > releases would be good for a growing community.
> >
> > Should we do a patch release every few months to include bug fixes?
> >
> > Sai
> >
> >
> > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
> wrote:
> >
> >> I have found it refreshing that the geode released cadence has been
> based
> >> on features being done,  rather than a set schedule.
> >>
> >> I come from an environment where we had quarterly releases and monthly
> >> patches to all supported previous releases, and I can tell you that it
> >> became a grind. That being said, within that release cadence a one-month
> >> ramp for bug fixes on the release branch was almost always sufficient.
> >>
> >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
> >>
> >>> +1 for scheduled releases and cutting the branch one month prior to
> >>> release. Given the time it took to fully root out, classify, and solve
> >>> issues with this 1.7 release, I think a month is the right amount of
> time
> >>> between cutting the branch and releasing.  If it ends up being too much
> >> or
> >>> too little, we can always adjust.
> >>>
> >>> I don’t feel strongly about the release cadence, but I generally favor
> >> more
> >>> frequent releases if possible (3 month over 6 month).  That way new
> >>> features can get into the hands of users sooner, assuming the feature
> >> takes
> >>> less than 3 months to complete.  Again, we can adjust the cadence if
> >>> necessary if it is too frequent or infrequent.
> >>>
> >>> Ryan
> >>>
> >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> >>> wrote:
> >>>
>  Anil, releasing every 3 months should give us 3 months of dev work.
> >> Don't
>  forget that there will be one month during which the next release is
>  already cut, but the vast majority of the work is going to the release
>  after that. So while we cut 1.7 one month ago and release 1.7 today,
> we
>  already have one month of work on develop again. It's not going to
> work
> >>> out
>  for this first release though, due to my suggestion to cut a month
> >> early
> >>> to
>  avoid holidays. If I recall correctly our past problem was that it
> took
>  longer to iron out issue on the release branch than expected. The
> >>> solution
>  to that would be to cut the release even earlier, but 1 month feels
> >> very
>  generous.
> 
>  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade  >
>  wrote:
> 
> > If I remember from earlier discussion; the plan was to deliver a
> >>> release
> > once 3 months. But from the past release history we had difficulty in
> > achieving that, either the features are not completely ready or the
> > bug-fixes have taken more time. We need verify what is right for
> >> Apache
> > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > depends on Geode release.
> > My vote will be for 4 or 6 months, as it provides at least 3+ month
> >> for
>  dev
> > activity and 1 month for QA.
> >
> > -Anil.
> >
> >
> > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> >
> >> +1 I definitely like the idea of scheduled releases.
> >>
> >> I wonder if cutting the release branch a month ahead of time is
>  overkill,
> >> but I guess we do seem to keep finding issues after the branch is
> >>> cut.
> >>
> >> -Dan
> >>
> >> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> >>> amurm...@pivotal.io>
> >> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I want

Re: proposing reduced default for "membership-port-range"

[Dan Smith]

+1

I think it's better not to have the possibility of a port collision for
people using Geode's default settings. Especially if you are using
automation to start and restart geode members, having a member fail to come
up randomly is problematic.

-Dan

On Thu, Oct 4, 2018 at 4:06 PM Brian Rowe  wrote:

> Currently the default value for this parameter covers the default locator
> and server port values.  As a result of this, when launching a locator and
> then a server on the same system using gfsh, it's possible to see the
> server fail because the locator has already bound the default server
> socket.  We've actually seen a couple of test runs fail with this issue.
>
> The proposed new range is 41000-61000, which, in addition to not
> overlapping the other default port values, has the benefit of being a
> subset of the linux ephemeral ports (for users who care about such
> things).  Please let me know if there are any objections to this change.
>
> Here's the current javadoc for this parameter:
>
> Description: The allowed range of ports for use in forming an unique
> membership identifier (UDP), for failure detection purposes (TCP) and to
> listen on for peer connections (TCP). This range is given as two numbers
> separated by a minus sign. Minimum 3 values in range are required to
> successfully startup.
> Default: 1024-65535
>

Re: [DISCUSS] Predictable minor release cadence

[Dan Smith]

Ok, I buy your arguments to cut the release branch 1 month ahead of time.
I'm fine with that plan, as long as we can stick to only putting critical
fixes on the release branch. Once the release branch is cut, it ships
without further changes unless we find new issues.

-Dan


On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
wrote:

> Robert and Sai, I think either release process can be stressful if your
> team doesn't understand that there is no faster button, but that the only
> lever is to cut scope (you can also compromise quality, but let's not do
> that).
> In either scenario there can be release pressure. To me the biggest
> difference is that with a fixed schedule I at least have a good chance to
> see sooner that I need to cut scope to catch the next train. Without a
> fixed schedule, I suddenly might find myself in the situation that everyone
> else is ready to ship and is waiting on me and getting impatient. I might
> have not even been able to see that coming unless I am constantly checking
> with everyone else to find out when they think they might be ready to ship.
>
> To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a
> massively growing community 😉
>
> On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
>
> > I’ve been advocating for a fixed release schedule for a long time.  3
> > months seems like a good rate given the release overhead.
> >
> > +1 on cutting the next release branch in November and shooting for an
> > early December v1.8.0 release.
> >
> > Anthony
> >
> >
> > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda  >
> > wrote:
> > >
> > > I agree with Robert that we should release based on features that go
> in.
> > >
> > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > These tools were evolving rapidly in the last couple of years and
> > frequent
> > > releases would be good for a growing community.
> > >
> > > Should we do a patch release every few months to include bug fixes?
> > >
> > > Sai
> > >
> > >
> > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
> > wrote:
> > >
> > >> I have found it refreshing that the geode released cadence has been
> > based
> > >> on features being done,  rather than a set schedule.
> > >>
> > >> I come from an environment where we had quarterly releases and monthly
> > >> patches to all supported previous releases, and I can tell you that it
> > >> became a grind. That being said, within that release cadence a
> one-month
> > >> ramp for bug fixes on the release branch was almost always sufficient.
> > >>
> > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> wrote:
> > >>
> > >>> +1 for scheduled releases and cutting the branch one month prior to
> > >>> release. Given the time it took to fully root out, classify, and
> solve
> > >>> issues with this 1.7 release, I think a month is the right amount of
> > time
> > >>> between cutting the branch and releasing.  If it ends up being too
> much
> > >> or
> > >>> too little, we can always adjust.
> > >>>
> > >>> I don’t feel strongly about the release cadence, but I generally
> favor
> > >> more
> > >>> frequent releases if possible (3 month over 6 month).  That way new
> > >>> features can get into the hands of users sooner, assuming the feature
> > >> takes
> > >>> less than 3 months to complete.  Again, we can adjust the cadence if
> > >>> necessary if it is too frequent or infrequent.
> > >>>
> > >>> Ryan
> > >>>
> > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> amurm...@pivotal.io>
> > >>> wrote:
> > >>>
> >  Anil, releasing every 3 months should give us 3 months of dev work.
> > >> Don't
> >  forget that there will be one month during which the next release is
> >  already cut, but the vast majority of the work is going to the
> release
> >  after that. So while we cut 1.7 one month ago and release 1.7 today,
> > we
> >  already have one month of work on develop again. It's not going to
> > work
> > >>> out
> >  for this first release though, due to my suggestion to cut a month
> > >> early
> > >>> to
> >  avoid holidays. If I recall correctly our past problem was that it
> > took
> >  longer to iron out issue on the release branch than expected. The
> > >>> solution
> >  to that would be to cut the release even earlier, but 1 month feels
> > >> very
> >  generous.
> > 
> >  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade <
> aging...@pivotal.io
> > >
> >  wrote:
> > 
> > > If I remember from earlier discussion; the plan was to deliver a
> > >>> release
> > > once 3 months. But from the past release history we had difficulty
> in
> > > achieving that, either the features are not completely ready or the
> > > bug-fixes have taken more time. We need verify what is right for
> > >> Apache
> > > Geode, 3, 4 or 6 months; and there is any community dev/activity
> that
> > > depends on Geode release.
> > > My vote will be for 4 or 6 months, as it provides 

Re: Queries on key fields

[anjana_nair]

Jason,

how can we use both together, isnt it redundant as both serve the same
purpose ? making retrieval faster ?



--
Sent from: http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/

Re: [DISCUSS] Predictable minor release cadence

[Kenneth Howe]

+1 to releasing on a 3-month schedule and cutting the branch a month before the 
release.

I’ve always felt that releasing based on content tends to prolong the 
test/release cycle. Some features are held up from getting released due to 
waiting for other features to be completed. Releasing on a relatively short 
fixed cadence means that new work “gets out there” quicker. Even if a new 
feature doesn’t yet have all the bells and whistles implemented, the project 
can get feedback sooner on the usability of what is there.

> On Oct 5, 2018, at 9:27 AM, Dan Smith  wrote:
> 
> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further changes unless we find new issues.
> 
> -Dan
> 
> 
> On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> wrote:
> 
>> Robert and Sai, I think either release process can be stressful if your
>> team doesn't understand that there is no faster button, but that the only
>> lever is to cut scope (you can also compromise quality, but let's not do
>> that).
>> In either scenario there can be release pressure. To me the biggest
>> difference is that with a fixed schedule I at least have a good chance to
>> see sooner that I need to cut scope to catch the next train. Without a
>> fixed schedule, I suddenly might find myself in the situation that everyone
>> else is ready to ship and is waiting on me and getting impatient. I might
>> have not even been able to see that coming unless I am constantly checking
>> with everyone else to find out when they think they might be ready to ship.
>> 
>> To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a
>> massively growing community 😉
>> 
>> On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
>> 
>>> I’ve been advocating for a fixed release schedule for a long time.  3
>>> months seems like a good rate given the release overhead.
>>> 
>>> +1 on cutting the next release branch in November and shooting for an
>>> early December v1.8.0 release.
>>> 
>>> Anthony
>>> 
>>> 
 On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda >> 
>>> wrote:
 
 I agree with Robert that we should release based on features that go
>> in.
 
 I am not sure if Apache Kafka & Spark are a good reference for GEODE.
 These tools were evolving rapidly in the last couple of years and
>>> frequent
 releases would be good for a growing community.
 
 Should we do a patch release every few months to include bug fixes?
 
 Sai
 
 
 On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
>>> wrote:
 
> I have found it refreshing that the geode released cadence has been
>>> based
> on features being done,  rather than a set schedule.
> 
> I come from an environment where we had quarterly releases and monthly
> patches to all supported previous releases, and I can tell you that it
> became a grind. That being said, within that release cadence a
>> one-month
> ramp for bug fixes on the release branch was almost always sufficient.
> 
> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
>> wrote:
> 
>> +1 for scheduled releases and cutting the branch one month prior to
>> release. Given the time it took to fully root out, classify, and
>> solve
>> issues with this 1.7 release, I think a month is the right amount of
>>> time
>> between cutting the branch and releasing.  If it ends up being too
>> much
> or
>> too little, we can always adjust.
>> 
>> I don’t feel strongly about the release cadence, but I generally
>> favor
> more
>> frequent releases if possible (3 month over 6 month).  That way new
>> features can get into the hands of users sooner, assuming the feature
> takes
>> less than 3 months to complete.  Again, we can adjust the cadence if
>> necessary if it is too frequent or infrequent.
>> 
>> Ryan
>> 
>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
>> amurm...@pivotal.io>
>> wrote:
>> 
>>> Anil, releasing every 3 months should give us 3 months of dev work.
> Don't
>>> forget that there will be one month during which the next release is
>>> already cut, but the vast majority of the work is going to the
>> release
>>> after that. So while we cut 1.7 one month ago and release 1.7 today,
>>> we
>>> already have one month of work on develop again. It's not going to
>>> work
>> out
>>> for this first release though, due to my suggestion to cut a month
> early
>> to
>>> avoid holidays. If I recall correctly our past problem was that it
>>> took
>>> longer to iron out issue on the release branch than expected. The
>> solution
>>> to that would be to cut the release even earlier, but 1 month feels
> very
>>> generous.
>>> 
>>> On Thu, Oct 4, 2018 at 4:04 PM Anilk

Folow-up last week's Geode Summit and SpringOne Platform

[Jagdish Mirani]

Hi Apache Geode Project users and devs:
We had an outstanding Geode Summit last week. This year we had 400+
attendees (previous years -  2016:80; 2017:180). I put together a short three
slide summary

with
links to the materials from the conference.

I also wanted to share my short intro presentation. This deck

has some interesting data on the Geode Project's progress, details of the
Geode agenda at the conference, where to find Geode resources, and how to
engage with the community.

Lastly, here are the video recordings of the sessions
.
Many of you who couldn't attend have already asked for the videos.

Thank you for all you effort on the Geode project - the effort is paying
off!!

-- 
Regards
Jag

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett]

Why not change the default behavior to that of port 0, letting the OS select an 
open ephemeral port if the user doesn’t specify a specific port?

> On Oct 5, 2018, at 9:02 AM, Dan Smith  wrote:
> 
> +1
> 
> I think it's better not to have the possibility of a port collision for
> people using Geode's default settings. Especially if you are using
> automation to start and restart geode members, having a member fail to come
> up randomly is problematic.
> 
> -Dan
> 
>> On Thu, Oct 4, 2018 at 4:06 PM Brian Rowe  wrote:
>> 
>> Currently the default value for this parameter covers the default locator
>> and server port values.  As a result of this, when launching a locator and
>> then a server on the same system using gfsh, it's possible to see the
>> server fail because the locator has already bound the default server
>> socket.  We've actually seen a couple of test runs fail with this issue.
>> 
>> The proposed new range is 41000-61000, which, in addition to not
>> overlapping the other default port values, has the benefit of being a
>> subset of the linux ephemeral ports (for users who care about such
>> things).  Please let me know if there are any objections to this change.
>> 
>> Here's the current javadoc for this parameter:
>> 
>> Description: The allowed range of ports for use in forming an unique
>> membership identifier (UDP), for failure detection purposes (TCP) and to
>> listen on for peer connections (TCP). This range is given as two numbers
>> separated by a minus sign. Minimum 3 values in range are required to
>> successfully startup.
>> Default: 1024-65535
>> 

Re: [DISCUSS] Predictable minor release cadence

[Dave Barnes]

If we go with more frequent releases, the number of available releases will
ramp up quickly.
What would be the best policy regarding earlier releases?
The Geode website's Release page currently links to 1.7.0, 1.6.0, 1.5.0,
and 1.4.0.
Would it be prudent to adopt a policy (as suggested by Craig Russell,
secretary of ASF) of keeping the available-via-mirror list short by
archiving older releases?
Does this present any hardship to users of older versions? Does it
introduce additional time into the release process that must be accounted
for?
-Dave

On Fri, Oct 5, 2018 at 9:27 AM Dan Smith  wrote:

> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further changes unless we find new issues.
>
> -Dan
>
>
> On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> wrote:
>
> > Robert and Sai, I think either release process can be stressful if your
> > team doesn't understand that there is no faster button, but that the only
> > lever is to cut scope (you can also compromise quality, but let's not do
> > that).
> > In either scenario there can be release pressure. To me the biggest
> > difference is that with a fixed schedule I at least have a good chance to
> > see sooner that I need to cut scope to catch the next train. Without a
> > fixed schedule, I suddenly might find myself in the situation that
> everyone
> > else is ready to ship and is waiting on me and getting impatient. I might
> > have not even been able to see that coming unless I am constantly
> checking
> > with everyone else to find out when they think they might be ready to
> ship.
> >
> > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and
> have a
> > massively growing community 😉
> >
> > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
> >
> > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > months seems like a good rate given the release overhead.
> > >
> > > +1 on cutting the next release branch in November and shooting for an
> > > early December v1.8.0 release.
> > >
> > > Anthony
> > >
> > >
> > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > > wrote:
> > > >
> > > > I agree with Robert that we should release based on features that go
> > in.
> > > >
> > > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > > These tools were evolving rapidly in the last couple of years and
> > > frequent
> > > > releases would be good for a growing community.
> > > >
> > > > Should we do a patch release every few months to include bug fixes?
> > > >
> > > > Sai
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  >
> > > wrote:
> > > >
> > > >> I have found it refreshing that the geode released cadence has been
> > > based
> > > >> on features being done,  rather than a set schedule.
> > > >>
> > > >> I come from an environment where we had quarterly releases and
> monthly
> > > >> patches to all supported previous releases, and I can tell you that
> it
> > > >> became a grind. That being said, within that release cadence a
> > one-month
> > > >> ramp for bug fixes on the release branch was almost always
> sufficient.
> > > >>
> > > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> > wrote:
> > > >>
> > > >>> +1 for scheduled releases and cutting the branch one month prior to
> > > >>> release. Given the time it took to fully root out, classify, and
> > solve
> > > >>> issues with this 1.7 release, I think a month is the right amount
> of
> > > time
> > > >>> between cutting the branch and releasing.  If it ends up being too
> > much
> > > >> or
> > > >>> too little, we can always adjust.
> > > >>>
> > > >>> I don’t feel strongly about the release cadence, but I generally
> > favor
> > > >> more
> > > >>> frequent releases if possible (3 month over 6 month).  That way new
> > > >>> features can get into the hands of users sooner, assuming the
> feature
> > > >> takes
> > > >>> less than 3 months to complete.  Again, we can adjust the cadence
> if
> > > >>> necessary if it is too frequent or infrequent.
> > > >>>
> > > >>> Ryan
> > > >>>
> > > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> > amurm...@pivotal.io>
> > > >>> wrote:
> > > >>>
> > >  Anil, releasing every 3 months should give us 3 months of dev
> work.
> > > >> Don't
> > >  forget that there will be one month during which the next release
> is
> > >  already cut, but the vast majority of the work is going to the
> > release
> > >  after that. So while we cut 1.7 one month ago and release 1.7
> today,
> > > we
> > >  already have one month of work on develop again. It's not going to
> > > work
> > > >>> out
> > >  for this first release though, due to my suggestion to cut a month
> > > >> early
> > > >>> to
> > >  avoid holidays. If I recall correctly our

Re: proposing reduced default for "membership-port-range"

[Dan Smith]

On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett  wrote:

> Why not change the default behavior to that of port 0, letting the OS
> select an open ephemeral port if the user doesn’t specify a specific port?
>

I think what we'd really like to do is change the cache server port to
something other than 40404. Maybe 0 (pick a port), or maybe something less
than 32K.

Unfortunately, on most linux distributions the ephemeral port range is 32K
-> 61K, which includes 40404, which I think is why Brian is proposing a
subset of that range.

-Dan

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett]

If we just default to 0 then the OS will pick is a port in whatever range is 
ephemeral and free. We don’t have to do any work. No need to define a range and 
seek an open port.

> On Oct 5, 2018, at 10:40 AM, Dan Smith  wrote:
> 
>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett  wrote:
>> 
>> Why not change the default behavior to that of port 0, letting the OS
>> select an open ephemeral port if the user doesn’t specify a specific port?
>> 
> 
> I think what we'd really like to do is change the cache server port to
> something other than 40404. Maybe 0 (pick a port), or maybe something less
> than 32K.
> 
> Unfortunately, on most linux distributions the ephemeral port range is 32K
> -> 61K, which includes 40404, which I think is why Brian is proposing a
> subset of that range.
> 
> -Dan

Re: [ANNOUNCE] Apache Geode 1.7.0

[Diane Hardman]

Woohoo! Awesome news. Congratulations to all the Geode committers and for
Naba's great work shepherding the release process!

On Thu, Oct 4, 2018 at 10:29 AM, Nabarun Nag  wrote:

> The Apache Geode community is pleased to announce the availability of
> Apache Geode 1.7.0.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> Geode 1.7.0 contains a number of improvements and bug fixes. It includes
> performance improvements in OQL order-by and distinct queries in
> client/server when security is enabled. New GFSH commands were added to
> get/set cluster config and to destroy gateway receivers. A new post
> processor was added to the new client protocol. Pulse now supports legacy
> SSL options. Auto-reconnecting members no more reuse old addresses and IDs.
> Duplicated or member-specific receivers are removed from cluster config
> during rolling upgrades. Users are encouraged to upgrade to the latest
> release.
>
> For the full list of changes please review the release notes:
> https://cwiki.apache.org/confluence/display/GEODE/
> Release+Notes#ReleaseNotes-1.7.0
>
> The release artifacts can be downloaded from the project website:
> http://geode.apache.org/releases/
>
> The release documentation is available at:
> http://geode.apache.org/docs/guide/17/about_geode.html
>
> We would like to thank all the contributors that made the release possible.
>
> Regards,
> Nabarun Nag on behalf of the Apache Geode team
>

Re: proposing reduced default for "membership-port-range"

[Dan Smith]

The problem is that the membership port is picked *first*. So it may pick
40404. Then, when the cache server tries to use port 40404, it gets a
collision.

-Dan

On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett  wrote:

> If we just default to 0 then the OS will pick is a port in whatever range
> is ephemeral and free. We don’t have to do any work. No need to define a
> range and seek an open port.
>
> > On Oct 5, 2018, at 10:40 AM, Dan Smith  wrote:
> >
> >> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett 
> wrote:
> >>
> >> Why not change the default behavior to that of port 0, letting the OS
> >> select an open ephemeral port if the user doesn’t specify a specific
> port?
> >>
> >
> > I think what we'd really like to do is change the cache server port to
> > something other than 40404. Maybe 0 (pick a port), or maybe something
> less
> > than 32K.
> >
> > Unfortunately, on most linux distributions the ephemeral port range is
> 32K
> > -> 61K, which includes 40404, which I think is why Brian is proposing a
> > subset of that range.
> >
> > -Dan
>

Re: [DISCUSS] Predictable minor release cadence

[Robert Houghton]

+1 to Dan

On Fri, Oct 5, 2018, 09:27 Dan Smith  wrote:

> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further changes unless we find new issues.
>
> -Dan
>
>
> On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> wrote:
>
> > Robert and Sai, I think either release process can be stressful if your
> > team doesn't understand that there is no faster button, but that the only
> > lever is to cut scope (you can also compromise quality, but let's not do
> > that).
> > In either scenario there can be release pressure. To me the biggest
> > difference is that with a fixed schedule I at least have a good chance to
> > see sooner that I need to cut scope to catch the next train. Without a
> > fixed schedule, I suddenly might find myself in the situation that
> everyone
> > else is ready to ship and is waiting on me and getting impatient. I might
> > have not even been able to see that coming unless I am constantly
> checking
> > with everyone else to find out when they think they might be ready to
> ship.
> >
> > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and
> have a
> > massively growing community 😉
> >
> > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
> >
> > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > months seems like a good rate given the release overhead.
> > >
> > > +1 on cutting the next release branch in November and shooting for an
> > > early December v1.8.0 release.
> > >
> > > Anthony
> > >
> > >
> > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > > wrote:
> > > >
> > > > I agree with Robert that we should release based on features that go
> > in.
> > > >
> > > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > > These tools were evolving rapidly in the last couple of years and
> > > frequent
> > > > releases would be good for a growing community.
> > > >
> > > > Should we do a patch release every few months to include bug fixes?
> > > >
> > > > Sai
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  >
> > > wrote:
> > > >
> > > >> I have found it refreshing that the geode released cadence has been
> > > based
> > > >> on features being done,  rather than a set schedule.
> > > >>
> > > >> I come from an environment where we had quarterly releases and
> monthly
> > > >> patches to all supported previous releases, and I can tell you that
> it
> > > >> became a grind. That being said, within that release cadence a
> > one-month
> > > >> ramp for bug fixes on the release branch was almost always
> sufficient.
> > > >>
> > > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> > wrote:
> > > >>
> > > >>> +1 for scheduled releases and cutting the branch one month prior to
> > > >>> release. Given the time it took to fully root out, classify, and
> > solve
> > > >>> issues with this 1.7 release, I think a month is the right amount
> of
> > > time
> > > >>> between cutting the branch and releasing.  If it ends up being too
> > much
> > > >> or
> > > >>> too little, we can always adjust.
> > > >>>
> > > >>> I don’t feel strongly about the release cadence, but I generally
> > favor
> > > >> more
> > > >>> frequent releases if possible (3 month over 6 month).  That way new
> > > >>> features can get into the hands of users sooner, assuming the
> feature
> > > >> takes
> > > >>> less than 3 months to complete.  Again, we can adjust the cadence
> if
> > > >>> necessary if it is too frequent or infrequent.
> > > >>>
> > > >>> Ryan
> > > >>>
> > > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> > amurm...@pivotal.io>
> > > >>> wrote:
> > > >>>
> > >  Anil, releasing every 3 months should give us 3 months of dev
> work.
> > > >> Don't
> > >  forget that there will be one month during which the next release
> is
> > >  already cut, but the vast majority of the work is going to the
> > release
> > >  after that. So while we cut 1.7 one month ago and release 1.7
> today,
> > > we
> > >  already have one month of work on develop again. It's not going to
> > > work
> > > >>> out
> > >  for this first release though, due to my suggestion to cut a month
> > > >> early
> > > >>> to
> > >  avoid holidays. If I recall correctly our past problem was that it
> > > took
> > >  longer to iron out issue on the release branch than expected. The
> > > >>> solution
> > >  to that would be to cut the release even earlier, but 1 month
> feels
> > > >> very
> > >  generous.
> > > 
> > >  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade <
> > aging...@pivotal.io
> > > >
> > >  wrote:
> > > 
> > > > If I remember from earlier discussion; the plan was to deliver a
> > > >>> release
> > > > once 3 months. But from the past release history we had

Re: [DISCUSS] Predictable minor release cadence

[Diane Hardman]

+1 to a regular cadence and starting with a 3-month cadence. As we learned
earlier this year, monthly was too frequent to support our testing cycles
and for users to update.

On Fri, Oct 5, 2018 at 11:54 AM, Robert Houghton 
wrote:

> +1 to Dan
>
> On Fri, Oct 5, 2018, 09:27 Dan Smith  wrote:
>
> > Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> > I'm fine with that plan, as long as we can stick to only putting critical
> > fixes on the release branch. Once the release branch is cut, it ships
> > without further changes unless we find new issues.
> >
> > -Dan
> >
> >
> > On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> > wrote:
> >
> > > Robert and Sai, I think either release process can be stressful if your
> > > team doesn't understand that there is no faster button, but that the
> only
> > > lever is to cut scope (you can also compromise quality, but let's not
> do
> > > that).
> > > In either scenario there can be release pressure. To me the biggest
> > > difference is that with a fixed schedule I at least have a good chance
> to
> > > see sooner that I need to cut scope to catch the next train. Without a
> > > fixed schedule, I suddenly might find myself in the situation that
> > everyone
> > > else is ready to ship and is waiting on me and getting impatient. I
> might
> > > have not even been able to see that coming unless I am constantly
> > checking
> > > with everyone else to find out when they think they might be ready to
> > ship.
> > >
> > > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and
> > have a
> > > massively growing community 😉
> > >
> > > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker 
> wrote:
> > >
> > > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > > months seems like a good rate given the release overhead.
> > > >
> > > > +1 on cutting the next release branch in November and shooting for an
> > > > early December v1.8.0 release.
> > > >
> > > > Anthony
> > > >
> > > >
> > > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> > sai.boorlaga...@gmail.com
> > > >
> > > > wrote:
> > > > >
> > > > > I agree with Robert that we should release based on features that
> go
> > > in.
> > > > >
> > > > > I am not sure if Apache Kafka & Spark are a good reference for
> GEODE.
> > > > > These tools were evolving rapidly in the last couple of years and
> > > > frequent
> > > > > releases would be good for a growing community.
> > > > >
> > > > > Should we do a patch release every few months to include bug fixes?
> > > > >
> > > > > Sai
> > > > >
> > > > >
> > > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > > wrote:
> > > > >
> > > > >> I have found it refreshing that the geode released cadence has
> been
> > > > based
> > > > >> on features being done,  rather than a set schedule.
> > > > >>
> > > > >> I come from an environment where we had quarterly releases and
> > monthly
> > > > >> patches to all supported previous releases, and I can tell you
> that
> > it
> > > > >> became a grind. That being said, within that release cadence a
> > > one-month
> > > > >> ramp for bug fixes on the release branch was almost always
> > sufficient.
> > > > >>
> > > > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> > > wrote:
> > > > >>
> > > > >>> +1 for scheduled releases and cutting the branch one month prior
> to
> > > > >>> release. Given the time it took to fully root out, classify, and
> > > solve
> > > > >>> issues with this 1.7 release, I think a month is the right amount
> > of
> > > > time
> > > > >>> between cutting the branch and releasing.  If it ends up being
> too
> > > much
> > > > >> or
> > > > >>> too little, we can always adjust.
> > > > >>>
> > > > >>> I don’t feel strongly about the release cadence, but I generally
> > > favor
> > > > >> more
> > > > >>> frequent releases if possible (3 month over 6 month).  That way
> new
> > > > >>> features can get into the hands of users sooner, assuming the
> > feature
> > > > >> takes
> > > > >>> less than 3 months to complete.  Again, we can adjust the cadence
> > if
> > > > >>> necessary if it is too frequent or infrequent.
> > > > >>>
> > > > >>> Ryan
> > > > >>>
> > > > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> > > amurm...@pivotal.io>
> > > > >>> wrote:
> > > > >>>
> > > >  Anil, releasing every 3 months should give us 3 months of dev
> > work.
> > > > >> Don't
> > > >  forget that there will be one month during which the next
> release
> > is
> > > >  already cut, but the vast majority of the work is going to the
> > > release
> > > >  after that. So while we cut 1.7 one month ago and release 1.7
> > today,
> > > > we
> > > >  already have one month of work on develop again. It's not going
> to
> > > > work
> > > > >>> out
> > > >  for this first release though, due to my suggestion to cut a
> month
> > > > >> early
> > > > >>> to
> > > >  avoid holidays. If I recall correctly our p

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett]

But if all ports where ephemeral by default then no collisions right? Why have 
any port have a default to a single fixed value or overlapping range of values. 
Since our opinionated use case is for clients to connect via locators then a 
known server port isn’t important. 

> On Oct 5, 2018, at 10:55 AM, Dan Smith  wrote:
> 
> The problem is that the membership port is picked *first*. So it may pick
> 40404. Then, when the cache server tries to use port 40404, it gets a
> collision.
> 
> -Dan
> 
>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett  wrote:
>> 
>> If we just default to 0 then the OS will pick is a port in whatever range
>> is ephemeral and free. We don’t have to do any work. No need to define a
>> range and seek an open port.
>> 
 On Oct 5, 2018, at 10:40 AM, Dan Smith  wrote:
 
 On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett 
>> wrote:
 
 Why not change the default behavior to that of port 0, letting the OS
 select an open ephemeral port if the user doesn’t specify a specific
>> port?
 
>>> 
>>> I think what we'd really like to do is change the cache server port to
>>> something other than 40404. Maybe 0 (pick a port), or maybe something
>> less
>>> than 32K.
>>> 
>>> Unfortunately, on most linux distributions the ephemeral port range is
>> 32K
>>> -> 61K, which includes 40404, which I think is why Brian is proposing a
>>> subset of that range.
>>> 
>>> -Dan
>> 

Re: proposing reduced default for "membership-port-range"

[Anthony Baker]

I think there are a lot of dependencies when deploying geode that rely on 
well-known ports and port ranges (e.g. exporting ports from a container, 
firewall rules, etc).  Changing the default server port from 40404 to ?? would 
break stuff.

Here’s the rule from our own Dockerfile:

# Default ports:
# RMI/JMX 1099
# REST 8080
# PULE 7070
# LOCATOR 10334
# CACHESERVER 40404
EXPOSE  8080 10334 40404 1099 7070

Anthony


> On Oct 5, 2018, at 1:45 PM, Jacob Barrett  wrote:
> 
> But if all ports where ephemeral by default then no collisions right? Why 
> have any port have a default to a single fixed value or overlapping range of 
> values. Since our opinionated use case is for clients to connect via locators 
> then a known server port isn’t important. 
> 
>> On Oct 5, 2018, at 10:55 AM, Dan Smith  wrote:
>> 
>> The problem is that the membership port is picked *first*. So it may pick
>> 40404. Then, when the cache server tries to use port 40404, it gets a
>> collision.
>> 
>> -Dan
>> 
>>> On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett  wrote:
>>> 
>>> If we just default to 0 then the OS will pick is a port in whatever range
>>> is ephemeral and free. We don’t have to do any work. No need to define a
>>> range and seek an open port.
>>> 
> On Oct 5, 2018, at 10:40 AM, Dan Smith  wrote:
> 
> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett 
>>> wrote:
> 
> Why not change the default behavior to that of port 0, letting the OS
> select an open ephemeral port if the user doesn’t specify a specific
>>> port?
> 
 
 I think what we'd really like to do is change the cache server port to
 something other than 40404. Maybe 0 (pick a port), or maybe something
>>> less
 than 32K.
 
 Unfortunately, on most linux distributions the ephemeral port range is
>>> 32K
 -> 61K, which includes 40404, which I think is why Brian is proposing a
 subset of that range.
 
 -Dan
>>> 

Re: [DISCUSS] Predictable minor release cadence

[Michael Stolz]

+1 on cutting in Nov.
Seems like community could benefit from one more release this year.

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Oct 5, 2018 8:45 AM, "Anthony Baker"  wrote:

> I’ve been advocating for a fixed release schedule for a long time.  3
> months seems like a good rate given the release overhead.
>
> +1 on cutting the next release branch in November and shooting for an
> early December v1.8.0 release.
>
> Anthony
>
>
> > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda 
> wrote:
> >
> > I agree with Robert that we should release based on features that go in.
> >
> > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > These tools were evolving rapidly in the last couple of years and
> frequent
> > releases would be good for a growing community.
> >
> > Should we do a patch release every few months to include bug fixes?
> >
> > Sai
> >
> >
> > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
> wrote:
> >
> >> I have found it refreshing that the geode released cadence has been
> based
> >> on features being done,  rather than a set schedule.
> >>
> >> I come from an environment where we had quarterly releases and monthly
> >> patches to all supported previous releases, and I can tell you that it
> >> became a grind. That being said, within that release cadence a one-month
> >> ramp for bug fixes on the release branch was almost always sufficient.
> >>
> >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
> >>
> >>> +1 for scheduled releases and cutting the branch one month prior to
> >>> release. Given the time it took to fully root out, classify, and solve
> >>> issues with this 1.7 release, I think a month is the right amount of
> time
> >>> between cutting the branch and releasing.  If it ends up being too much
> >> or
> >>> too little, we can always adjust.
> >>>
> >>> I don’t feel strongly about the release cadence, but I generally favor
> >> more
> >>> frequent releases if possible (3 month over 6 month).  That way new
> >>> features can get into the hands of users sooner, assuming the feature
> >> takes
> >>> less than 3 months to complete.  Again, we can adjust the cadence if
> >>> necessary if it is too frequent or infrequent.
> >>>
> >>> Ryan
> >>>
> >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> >>> wrote:
> >>>
>  Anil, releasing every 3 months should give us 3 months of dev work.
> >> Don't
>  forget that there will be one month during which the next release is
>  already cut, but the vast majority of the work is going to the release
>  after that. So while we cut 1.7 one month ago and release 1.7 today,
> we
>  already have one month of work on develop again. It's not going to
> work
> >>> out
>  for this first release though, due to my suggestion to cut a month
> >> early
> >>> to
>  avoid holidays. If I recall correctly our past problem was that it
> took
>  longer to iron out issue on the release branch than expected. The
> >>> solution
>  to that would be to cut the release even earlier, but 1 month feels
> >> very
>  generous.
> 
>  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade  >
>  wrote:
> 
> > If I remember from earlier discussion; the plan was to deliver a
> >>> release
> > once 3 months. But from the past release history we had difficulty in
> > achieving that, either the features are not completely ready or the
> > bug-fixes have taken more time. We need verify what is right for
> >> Apache
> > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > depends on Geode release.
> > My vote will be for 4 or 6 months, as it provides at least 3+ month
> >> for
>  dev
> > activity and 1 month for QA.
> >
> > -Anil.
> >
> >
> > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> >
> >> +1 I definitely like the idea of scheduled releases.
> >>
> >> I wonder if cutting the release branch a month ahead of time is
>  overkill,
> >> but I guess we do seem to keep finding issues after the branch is
> >>> cut.
> >>
> >> -Dan
> >>
> >> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> >>> amurm...@pivotal.io>
> >> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I want to propose shipping Geode on a regular cadence. My
> >> concrete
> >> proposal
> >>> is to ship Geode every 3 months on the first weekday. To make
> >> sure
> >>> we
> > hit
> >>> that date we would cut the release 1 months prior to that day.
> >>>
> >>> *Why?*
> >>> Knowing on what day the release will get cut and on what day we
> >>> ship
> >> allows
> >>> community members to plan their contributions. If I want my
> >> feature
>  to
> > be
> >>> in the next release I know by when I need to have it merged to
>  develop
> >> and
> >>> can plan accordingly. As a user who is waiting for a particular
>  feature

goodbye LogWriterI18n

[Bruce Schuchardt]

I've just checked in a fairly large set of changes to remove all uses of 
LogWriterI18n and to remove the LocalizedStrings.java class altogether.  
The other I18n classes are still in place because they are in a public 
package or are needed to make that stuff compile, but you should no 
longer use them.


From now on please use the new log4j-based log service.  If you must 
use a LogWriter do not use the LogWriterI18n variant because you no 
longer have a good framework for creating StringIDs to feed to its 
methods.  Just use regular Strings.

Re: goodbye LogWriterI18n

[Jacob Barrett]

Perhaps it would be wise to create a JIRA that lists things, like this, we 
would like to remove from the public API come 2.0 so we don’t forget.

> On Oct 5, 2018, at 3:02 PM, Bruce Schuchardt  wrote:
> 
> I've just checked in a fairly large set of changes to remove all uses of 
> LogWriterI18n and to remove the LocalizedStrings.java class altogether.  The 
> other I18n classes are still in place because they are in a public package or 
> are needed to make that stuff compile, but you should no longer use them.
> 
> From now on please use the new log4j-based log service.  If you must use a 
> LogWriter do not use the LogWriterI18n variant because you no longer have a 
> good framework for creating StringIDs to feed to its methods.  Just use 
> regular Strings.
> 
> 

Re: proposing reduced default for "membership-port-range"

[Jacob Barrett]

So in the Dockerfile you explicitly set the server to start on port 40404, 
problem solved. In whatever environment where you need it on a specific port 
you then assign that port. But for all the other cases where we don’t need to 
know it, like most of the time, it should just pick something ephemeral and 
work.


> On Oct 5, 2018, at 1:57 PM, Anthony Baker  wrote:
> 
> I think there are a lot of dependencies when deploying geode that rely on 
> well-known ports and port ranges (e.g. exporting ports from a container, 
> firewall rules, etc).  Changing the default server port from 40404 to ?? 
> would break stuff.
> 
> Here’s the rule from our own Dockerfile:
> 
> # Default ports:
> # RMI/JMX 1099
> # REST 8080
> # PULE 7070
> # LOCATOR 10334
> # CACHESERVER 40404
> EXPOSE  8080 10334 40404 1099 7070
> 
> Anthony
> 
> 
>> On Oct 5, 2018, at 1:45 PM, Jacob Barrett  wrote:
>> 
>> But if all ports where ephemeral by default then no collisions right? Why 
>> have any port have a default to a single fixed value or overlapping range of 
>> values. Since our opinionated use case is for clients to connect via 
>> locators then a known server port isn’t important. 
>> 
>>> On Oct 5, 2018, at 10:55 AM, Dan Smith  wrote:
>>> 
>>> The problem is that the membership port is picked *first*. So it may pick
>>> 40404. Then, when the cache server tries to use port 40404, it gets a
>>> collision.
>>> 
>>> -Dan
>>> 
 On Fri, Oct 5, 2018 at 10:52 AM Jacob Barrett  wrote:
 
 If we just default to 0 then the OS will pick is a port in whatever range
 is ephemeral and free. We don’t have to do any work. No need to define a
 range and seek an open port.
 
>> On Oct 5, 2018, at 10:40 AM, Dan Smith  wrote:
>> 
>> On Fri, Oct 5, 2018 at 10:31 AM Jacob Barrett 
 wrote:
>> 
>> Why not change the default behavior to that of port 0, letting the OS
>> select an open ephemeral port if the user doesn’t specify a specific
 port?
>> 
> 
> I think what we'd really like to do is change the cache server port to
> something other than 40404. Maybe 0 (pick a port), or maybe something
 less
> than 32K.
> 
> Unfortunately, on most linux distributions the ephemeral port range is
 32K
> -> 61K, which includes 40404, which I think is why Brian is proposing a
> subset of that range.
> 
> -Dan
 
> 

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1061 was SUCCESSFUL (with 2456 tests). Change made by John Blum.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #1061 was successful.
---
Scheduled with changes by John Blum.
2458 tests in total.

https://build.spring.io/browse/SGF-NAG-1061/




--
Code Changes
--
John Blum (b4ff689afd21c6ffc66671583e970bd0d2287cb3):

>DATAGEODE-148 - Upgrade to Apache Geode 1.7.0.



--
This message is automatically generated by Atlassian Bamboo

Re: goodbye LogWriterI18n

[Bruce Schuchardt]

 I think there's already one listing all of the deprecated APIs. This 
is one of them.  issues.appache.org doesn't seem to be reachable from my 
machine this afternoon or I'd look up the ticket number.



On 10/5/18 3:38 PM, Jacob Barrett wrote:

Perhaps it would be wise to create a JIRA that lists things, like this, we 
would like to remove from the public API come 2.0 so we don’t forget.


On Oct 5, 2018, at 3:02 PM, Bruce Schuchardt  wrote:

I've just checked in a fairly large set of changes to remove all uses of 
LogWriterI18n and to remove the LocalizedStrings.java class altogether.  The 
other I18n classes are still in place because they are in a public package or 
are needed to make that stuff compile, but you should no longer use them.

 From now on please use the new log4j-based log service.  If you must use a 
LogWriter do not use the LogWriterI18n variant because you no longer have a 
good framework for creating StringIDs to feed to its methods.  Just use regular 
Strings.

Re: goodbye LogWriterI18n

[Jacob Barrett]

Maybe because you have too many Ps in your url. ;)

> On Oct 5, 2018, at 3:56 PM, Bruce Schuchardt  wrote:
> 
>  I think there's already one listing all of the deprecated APIs. This is one 
> of them.  issues.appache.org doesn't seem to be reachable from my machine 
> this afternoon or I'd look up the ticket number.
> 
> 
>> On 10/5/18 3:38 PM, Jacob Barrett wrote:
>> Perhaps it would be wise to create a JIRA that lists things, like this, we 
>> would like to remove from the public API come 2.0 so we don’t forget.
>> 
>>> On Oct 5, 2018, at 3:02 PM, Bruce Schuchardt  wrote:
>>> 
>>> I've just checked in a fairly large set of changes to remove all uses of 
>>> LogWriterI18n and to remove the LocalizedStrings.java class altogether.  
>>> The other I18n classes are still in place because they are in a public 
>>> package or are needed to make that stuff compile, but you should no longer 
>>> use them.
>>> 
>>> From now on please use the new log4j-based log service.  If you must use a 
>>> LogWriter do not use the LogWriterI18n variant because you no longer have a 
>>> good framework for creating StringIDs to feed to its methods.  Just use 
>>> regular Strings.
>>> 
>>> 
> 

Re: goodbye LogWriterI18n

[Galen O'Sullivan]

This is excellent. Thanks for this improvement, Bruce.

On Fri, Oct 5, 2018 at 4:14 PM Jacob Barrett  wrote:

> Maybe because you have too many Ps in your url. ;)
>
> > On Oct 5, 2018, at 3:56 PM, Bruce Schuchardt 
> wrote:
> >
> >  I think there's already one listing all of the deprecated APIs. This is
> one of them.  issues.appache.org doesn't seem to be reachable from my
> machine this afternoon or I'd look up the ticket number.
> >
> >
> >> On 10/5/18 3:38 PM, Jacob Barrett wrote:
> >> Perhaps it would be wise to create a JIRA that lists things, like this,
> we would like to remove from the public API come 2.0 so we don’t forget.
> >>
> >>> On Oct 5, 2018, at 3:02 PM, Bruce Schuchardt 
> wrote:
> >>>
> >>> I've just checked in a fairly large set of changes to remove all uses
> of LogWriterI18n and to remove the LocalizedStrings.java class altogether.
> The other I18n classes are still in place because they are in a public
> package or are needed to make that stuff compile, but you should no longer
> use them.
> >>>
> >>> From now on please use the new log4j-based log service.  If you must
> use a LogWriter do not use the LogWriterI18n variant because you no longer
> have a good framework for creating StringIDs to feed to its methods.  Just
> use regular Strings.
> >>>
> >>>
> >
>

creating Thread, ThreadFactory, or Executor instances in geode

[Darrel Schneider]

When a thread runs, if it throws an exception that is not caught, then that
exception will just silently kill your thread. This can make it very hard
to diagnose what is happening. To remedy this situation in geode, a long
time ago it introduced a LoggingThreadGroup class. As long as you created
one of these groups and put your thread in it, then the uncaught exception
would be logged to the geode logger.
One of the problems with LoggingThreadGroup was that it kept a static
collection of all the instances of it. In some places this lead to memory
leak problems. Also geode had many places in its code that forgot to use
this in favor of some other JDK API that created a thread that would not
have a geode LoggingThreadGroup.
Today fixes for GEODE-5780 and GEODE-5783 were done that remove
LoggingThreadGroup.
Now if you want to create a thread use LoggingThread. You can either
directly create an instance of it of subclass it.
If you want a ThreadFactory use LoggingThreadFactory.
If you want an Executor using LoggingExecutors (which even has support for
a work stealing pool which will log).

All of these classes register with any thread they create a singleton
instance of LoggingUncaughtExceptionHandler that will log uncaught
exceptions to a Logger. If you find some other way that you need to create
a thread that can not use LoggingThread, LoggingThreadFactory, or
LoggingExecutors then you should at least register your thread instance
with LoggingUncaughtExceptionHandler by calling the "setOnThread(Thread)"
method on it.

Let me know if you have any questions about how to create threads in geode.