I wouldn't recommend using both together as this combo is completely untested. Users who do this are literally the only folks who have even tried running this way. I recommend supporting only what we've tested.
-Kirk On Mon, Jul 25, 2016 at 12:27 PM, Michael Stolz <mst...@pivotal.io> wrote: > 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 > > > > > >
