If such a change is to be introduced.. maybe we call it `SYSTEM_PREFIX` or something more generic that we could use within the Geode.

Then we could hopefully cover many to most `gemfire` vs `geode` renaming.

But I agree with @Anthony, if we aren't 100% certain about a change then we should hold off until the next release. There is always tomorrow. :D


On 14/10/16 8:05 am, Swapnil Bawaskar wrote:
How about introducing a new GEMFIRE_FILE_PREFIX attribute that will default
to "geode" while leaving GEMFIRE_PREFIX default to "gemfire"? Is this
something that will work?

On Thu, Oct 13, 2016 at 1:48 PM, Anthony Baker <aba...@pivotal.io> wrote:

Hmmm, you would think it would be easier to change a file name :-)

I don’t think we should be pushing destabilizing changes into a release
branch.  If the changes aren’t ready now we always pick them up for the
next release.


On Oct 13, 2016, at 1:13 PM, Kirk Lund <kl...@apache.org> wrote:

I'm currently working with Jared and we have spent a few days working
on GEODE-1466. We've been trying to get geode to the point where it can
automatically search for, find and use either geode.properties or
gemfire.properties (preferring geode.properties if both are found).

We were intending to break this up into three subtasks with the hope of
including #1 in Geode 1.0.0 incubating:

1) locating geode.properties and gemfire.properties if user has not
specified a specific properties file

2) support specifying geode configuration properties with system
geode.<property-name> as well as gemfire.<property-name>

ex: -Dgemfire.off-heap-memory-size=40g or -Dgeode.off-heap-memory-size=
3) modify all other system properties in geode to support alias of
as well as geode where the name of the system property currently contains

ex: -Dgemfire.Query.VERBOSE=true or -Dgeode.Query.VERBOSE=true

The community is planning to create the Geode 1.0.0 incubating RC
The work we have completed so far involves modifying geode to search for
both geode.properties and gemfire.properties to use whichever one is
This turns out to be too complex to complete by tomorrow (send me a email
directly if you want more detailed info which mostly involves
DistributionConfig and ConfigSource).

In order to complete this in time, we need to use a different strategy.
Instead of looking for geode.properties first and then
we are proposing the following change to DistributionConfig:

Change the GEMFIRE_PREFIX = "gemfire." constant to be configurable by a
system property and change the default to be "geode." This places a
burden on the user who is migrating from GemFire to Geode but doesn't
to rename gemfire.properties or gemfire system properties. By default,
Geode would search for geode.properties unless the user specifies a new
system property with a different prefix ("gemfire."):

String GEMFIRE_PREFIX = PropertiesPrefix.getGemfireOrGeodePrefix();

Example of overriding this to be "gemfire.":


(we'll add the "." for you if you leave it out)

Pivotal or other vendors could also alter this prefix as they see fit.

There are 453 lines of production code that refer to this GEMFIRE_PREFIX
constant. For example, every system property that contains "gemfire." is
currently referring to the constant, so they would also be altered to be
"geode." by default. The JMX notifications also refer to GEMFIRE_PREFIX
such as: GEMFIRE_PREFIX + "distributedsystem.cache.client.joined".

Does anyone know if anything referring to GEMFIRE_PREFIX is persisted in
some way that would break if we make this change? For example, if we
persist any strings built with this constant to a diskstore, then
from that diskstore would be broken if the prefix value is "geode."
recovery of an old diskstore.

Also, a user could conceivably override the GEMFIRE_PREFIX in some
of a cluster but not others which could break things in unexpected ways.

One more note: While reviewing uses of GEMFIRE_PREFIX we noticed that
AgentUtil supports "GEMFIRE" (hardcoded) and GEMFIRE_PREFIX+".home" env
vars while all of the online docs specify setting GEMFIRE_HOME as an env
var. I suspect this is already broken (I will file a ticket), but I think
we will also be at risk of breaking additional things that may or may not
be immediately detected by precheckin tests. It's also used by
for the name of a dtd: new File(GEMFIRE_PREFIX + "dtd). We'll continue
looking for unusual or risky uses of the constant.

Bottom line is making this change is higher risk than not making the
change, and there could be some fallout bugs that require fixes and
additional release candidates for 1.0.0.

Does the community feel this change is desirable for 1.0.0? Or is it
to leave it as "gemfire." and move GEODE-1466 to post-1.0.0?


Reply via email to