creating Thread, ThreadFactory, or Executor instances in geode

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 on

Re: goodbye LogWriterI18n

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. Th

Re: goodbye LogWriterI18n

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

Re: goodbye LogWriterI18n

 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

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

--- Spring Data GemFire > Nightly-ApacheGeode > #1061 was successful. --- Scheduled with changes by John Blum. 2458 tests in total. https://build.spring.io/brows

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

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 ephe

Re: goodbye LogWriterI18n

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 an

goodbye LogWriterI18n

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

Re: [DISCUSS] Predictable minor release cadence

+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 > mont

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

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 port

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

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

Re: [DISCUSS] Predictable minor release cadence

+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: > > >

Re: [DISCUSS] Predictable minor release cadence

+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

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

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 e

Re: [ANNOUNCE] Apache Geode 1.7.0

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 dat

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

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

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

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

Re: [DISCUSS] Predictable minor release cadence

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 Rus

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

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 Geod

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

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

Re: [DISCUSS] Predictable minor release cadence

+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 re

Re: Queries on key fields

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

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

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

+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 wr

Re: [DISCUSS] Predictable minor release cadence

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 diffe

Re: [DISCUSS] Predictable minor release cadence

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: >