Re: use-cluster-configuration/cache.xml/reconnect

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

Re: use-cluster-configuration/cache.xml/reconnect

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) so

Re: use-cluster-configuration/cache.xml/reconnect

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 wrote:

Re: use-cluster-configuration/cache.xml/reconnect

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

Re: use-cluster-configuration/cache.xml/reconnect

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 n

Re: use-cluster-configuration/cache.xml/reconnect

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 wrote: > There are still some

Re: use-cluster-configuration/cache.xml/reconnect

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-

Re: use-cluster-configuration/cache.xml/reconnect

Hi Kirk- FYI, SDG disables [1] *cluster config*, and especially, *auto-reconnect* by default. Having a peer cache "application" configured wit

Re: use-cluster-configuration/cache.xml/reconnect

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 GemFi