There are still some things that can't be configured with cluster configuration service so the combination of cluster-configuration-service=true and cache.xml will have to be supported until such time as CCS is completed.
-- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: 631-835-4771 On Mon, Jul 25, 2016 at 11:55 AM, Barry Oglesby <bogle...@pivotal.io> wrote: > I'm not seeing this behavior in my tests. I have a cache.xml and > use-cluster-configuration=true. When the member recovers, I see the xml > being recreated. > > The GMSMembershipManager.saveCacheXmlForReconnect method is being invoked > but short-circuiting because sharedConfigEnabled=true. > > But, the GemFireCacheImpl.initializeDeclarativeCache method is invoked and > that recreates the cache. > > I see this logging from the ReconnectThread: > > [info 2016/07/25 11:33:08.831 PDT server <ReconnectThread> tid=0x3e] > Received cluster configuration from the locator > > [info 2016/07/25 11:33:08.831 PDT server <ReconnectThread> tid=0x3e] > Received an empty shared configuration > > [info 2016/07/25 11:33:08.831 PDT server <ReconnectThread> tid=0x3e] > Initializing cache using "file:/.../config/gemfire-server.xml": > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE cache PUBLIC > "-//GemStone Systems, Inc.//GemFire Declarative Caching 7.0//EN" > "http://www.gemstone.com/dtd/cache7_0.dtd";> > > <cache> > <cache-server port="0"/> > <region name="data" refid="PARTITION_REDUNDANT"/> > <function-service> > <function> > <class-name>MembershipCycleHealthFunction</class-name> > </function> > </function-service> > </cache> > > What exact configuration is being used that is failing? > > Thanks, > Barry Oglesby > > > On Mon, Jul 25, 2016 at 10:44 AM, Kirk Lund <kl...@pivotal.io> wrote: > > > Below came to me via support engineer, and I'm trying to determine what > the > > correct behavior should be: > > > > "Let's assume that you're configuring your entire cache through spring or > > cache.xml without using the cluster configuration service, and that > you're > > using the default settings when starting the cluster (meaning > > "-Dgemfire.use-cluster-configuration=true"). Under these circumstances, > if > > a member is kicked out of the distributed system, it'll be useless after > > the auto reconnect feature kicks in because it detects that the cluster > > configuration is enabled and tries to recover the configuration from it, > > even when it's actually empty because it's not being used at all. > > > > According to the user guide we actually support this kind of setup > (cluster > > configuration plus member group configuration plus individual member > > configuration), but the actual source code used when reconnecting doesn't > > support it at all." > > > > Apparently use-cluster-configuration=true, but the user actually used > > cache.xml to configure the cache server. > > > > 1) I thought we were going to disallow mixing cluster config with old > > config in this way. > > > > 2) I would expect that starting a server with a cache.xml AND > > use-cluster-configuration=true > > should fail fast and not be allowed to start. > > > > 3) I would also expect that if a locator is configured with > > use-cluster-configuration=true > > then it should reject any cache servers that attempt to join the cluster > > that have use-cluster-configuration=false. > > > > I still need to find the relevant section in the user guide, but I would > > propose changing this to NOT allow cluster config to be used with old > > config. This is untested and be unsupported. The documentation should NOT > > say this is ok to do. > > > > Thoughts? > > > > -Kirk > > >
