It sounds like maybe we need to modify the docs to tell users to not enable reconnect when configuring the Cache with Spring.
Is there anything else we can do like detect this in some way and refuse to allow the configuration to startup? -Kirk On Monday, July 25, 2016, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > But as John pointed out, you shouldn't use auto-reconnect with Spring. > Spring has injected references to the old cache and regions into > applications and they won't know about the new cache. Auto-reconnect > doesn't rebuild the old cache - it creates a new one with its own identity. > > Le 7/25/2016 à 2:34 PM, Barry Oglesby a écrit : > >> 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 >>>>>> >>>>>> >
