geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kmil...@apache.org
Subject geode git commit: GEODE-2180 Autoreconnect with API configuration detail
Date Tue, 06 Dec 2016 17:43:26 GMT
Repository: geode
Updated Branches:
  refs/heads/develop 4876c784b -> 0bd9fc97a


GEODE-2180 Autoreconnect with API configuration detail

Autoreconnect assumes valid XML configuration (from the
default use of the cluster config svc).  That doesn't
work if the cache is configured using API calls.  So,
document this, and suggest disabling either default use
of autoreconnect or default use of the cluster configuration
service.


Project: http://git-wip-us.apache.org/repos/asf/geode/repo
Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/0bd9fc97
Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/0bd9fc97
Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/0bd9fc97

Branch: refs/heads/develop
Commit: 0bd9fc97acd85cbd4e86d139557b814f1fdf5d55
Parents: 4876c78
Author: Karen Miller <kmiller@pivotal.io>
Authored: Mon Dec 5 10:47:51 2016 -0800
Committer: Karen Miller <kmiller@pivotal.io>
Committed: Tue Dec 6 09:42:50 2016 -0800

----------------------------------------------------------------------
 .../autoreconnect/member-reconnect.html.md.erb  | 28 ++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/geode/blob/0bd9fc97/geode-docs/managing/autoreconnect/member-reconnect.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/autoreconnect/member-reconnect.html.md.erb b/geode-docs/managing/autoreconnect/member-reconnect.html.md.erb
index 916d301..8d59c0a 100644
--- a/geode-docs/managing/autoreconnect/member-reconnect.html.md.erb
+++ b/geode-docs/managing/autoreconnect/member-reconnect.html.md.erb
@@ -23,13 +23,37 @@ A Geode member may be forcibly disconnected from a Geode distributed system
if t
 
 ## How the Autoreconnection Process Works
 
-After being disconnected from a distributed system a Geode member shuts down and then automatically
restarts into a "reconnecting" state, while periodically attempting to rejoin the distributed
system by contacting a list of known locators. If the member succeeds in reconnecting to a
known locator, the member rebuilds its view of the distributed system from existing members
and receives a new distributed system ID.
+After being disconnected from a distributed system,
+a Geode member shuts down and, by default, automatically restarts into 
+a "reconnecting" state,
+while periodically attempting to rejoin the distributed system 
+by contacting a list of known locators.
+If the member succeeds in reconnecting to a known locator, the member rebuilds its view of
the distributed system from existing members and receives a new distributed member ID.
 
 If the member cannot connect to a known locator, the member will then check to see if it
itself is a locator (or hosting an embedded locator process). If the member is a locator,
then the member does a quorum-based reconnect; it will attempt to contact a quorum of the
members that were in the membership view just before it became disconnected. If a quorum of
members can be contacted, then startup of the distributed system is allowed to begin. Since
the reconnecting member does not know which members survived the network partition event,
all members that are in a reconnecting state will keep their UDP unicast ports open and respond
to ping requests.
 
 Membership quorum is determined using the same member weighting system used in network partition
detection. See [Membership Coordinators, Lead Members and Member Weighting](../network_partitioning/membership_coordinators_lead_members_and_weighting.html#concept_23C2606D59754106AFBFE17515DF4330).
 
-Note that when a locator is in the reconnecting state, it provides no discovery services
for the distributed system.
+Note that when a locator is in the reconnecting state,
+it provides no discovery services for the distributed system.
+
+The default settings for reconfiguration of the cache once
+reconnected assume that the cluster configuration service has
+a valid (XML) configuration.
+This will not be the case if the cluster was configured using
+API calls.
+To handle this case,
+either disable autoreconnect by setting the property to
+
+```
+disable-auto-reconnect = true
+```
+
+or, disable the cluster configuration service by setting the property to
+
+```
+enable-cluster-configuration = false
+```
 
 After the cache has reconnected, applications must fetch a reference to the new Cache, Regions,
DistributedSystem and other artifacts. Old references will continue to throw cancellation
exceptions like `CacheClosedException(cause=ForcedDisconnectException)`.
 


Mime
View raw message