For *Spring (Data GemFire)* applications, I don't strictly refuse this configuration, as it is a valid configuration. It's just *not* enabled by *default* since most *Spring* configured members (GemFire peer cache) are "applications" that use the GemFire components/objects (Cache, Regions, etc) some unique way (such as in DAOs).
However, if users are using SDG to strictly configure their GemFire Peer Cache data nodes/cluster members over cache.xml, or even Cluster Config, then it might be perfectly valid to allow them to enable "auto-reconnect" since there's (possibly) no Cache/Region/etc references being injected anywhere (as in the case when it is not an "application"). enable-cluster-configuration is less risky and works in harmony with *Spring* config. Essentially, *Spring* config "augments" anything coming from Cluster Config, to enable features/create components/objects in GemFire specific to the application's needs. I just disable enable-cluster-configuration by default since our preference would be to have users use *Spring* to configure the member. This will become even more prevalent as *Spring Boot* auto-configuration gets applied to GemFire applications using Spring (Data GemFire). ... I have a few surprises lined up in SDG that I can present on Wednesday if anyone is interested; I think users will be ecstatic about what I am planning in SD GemFire 1.9 and SD Geode 1.0.0.APACHE-GEODE-INCUBATING-M3. I am excited to be working on it. In a nutshell... it will be the equivalent of the *Spring Boot* experience (like, but not specifically the @SpringBootApplication, hint, hint) applied to GemFire/Geode applications using SDG to get up and running quickly and easily, with minimal fuss. -John On Mon, Jul 25, 2016 at 6:45 PM, Kirk Lund <kl...@pivotal.io> wrote: > 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 > >>>>>> > >>>>>> > > > -- -John 503-504-8657 john.blum10101 (skype)
