Hi Kirk- FYI, SDG disables <https://github.com/spring-projects/spring-data-gemfire/blob/1.8.2.RELEASE/src/main/java/org/springframework/data/gemfire/CacheFactoryBean.java#L154-L157> [1] *cluster config*, and especially, *auto-reconnect* by default.
Having a peer cache "application" configured with SDG try to reconnect, and successfully do so, is decidedly BAD for those applications where they have injected *Cache* and *Region* references, and they will. Those reference upon reconnect will be stale and essentially the application will need to be rebooted. I have tried to think of ways to handle this (e.g. Proxies), but it gets missy/tricky real fast. As for cluster configuration, I think it is highly valid to use both Cluster Config and SDG config or perhaps cache.xml in the same instance and I don't think we should disallow this. Having a local config (per node) is useful in situations where the peer cache "application" needs to extend and build on the (base) Cluster Config coming from the cluster, with application specific objects (additional Regions, Indexes, etc) that might not pertain to all members in the cluster. I have even seen this done at a few customer sites and I also provide test coverage for this in SDG. So... 1) NO 2) NO 3) Please/Definitely NO Let me know if you need additional insight. Thanks, John [1] https://github.com/spring-projects/spring-data-gemfire/blob/1.8.2.RELEASE/src/main/java/org/springframework/data/gemfire/CacheFactoryBean.java#L154-L157 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)
