John, I'll save my questions for your SDG talk. Thanks!
-Kirk On Mon, Jul 25, 2016 at 6:59 PM, John Blum <jb...@pivotal.io> wrote: > 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) >
