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
