I see the difference in our tests. Juan is using spring to configure the cache, not cache.xml. In my test, I used just cache.xml. I read in his bug "through spring or cache.xml", so I just did cache.xml, but its the spring part of that statement that is relevant.
With spring config, the cache is not reloaded. When the server is started initially, the ServerLauncher startWithSpring method is invoked which uses the SpringContextBootstrappingInitializer to initialize the cache. That doesn't happen on reconnect. Reconnect will save or reload the config in one of two ways: - if use-cluster-configuration=false (in JGroupMembershipManager saveCacheXmlForReconnect) - if the cache-xml-file is set (in GemFireCacheImpl logCacheXML) Neither of these are true in the spring-only configuration, so nothing is reloaded. Thanks, Barry Oglesby On Mon, Jul 25, 2016 at 1:05 PM, Kirk Lund <kl...@pivotal.io> wrote: > 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 > > > > > > > > > >
