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 properties
geode.<property-name> as well as gemfire.<property-name>
ex: -Dgemfire.off-heap-memory-size=40g or -Dgeode.off-heap-memory-size=40g
3) modify all other system properties in geode to support alias of gemfire
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 tomorrow.
The work we have completed so far involves modifying geode to search for
both geode.properties and gemfire.properties to use whichever one is found.
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 gemfire.properties,
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 greater
burden on the user who is migrating from GemFire to Geode but doesn't want
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 recovery
from that diskstore would be broken if the prefix value is "geode." during
recovery of an old diskstore.
Also, a user could conceivably override the GEMFIRE_PREFIX in some members
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 DtdResolver
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 better
to leave it as "gemfire." and move GEODE-1466 to post-1.0.0?