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
>
