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
