Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Complete
-
None
-
Spring and GemFire 7.5 (Cedar)
Description
When a GemFire member data node fails due to a system or network error, the member is forced out of the GemFire distributed system (cluster). The member will then, if possible, start an orderly shutdown followed by a reconnect attempt to the cluster, which results in a reinitialization of the Cache.
In the GemFire team's own words...
In GemFire 7.0 and earlier releases a member of the peer-to-peer cache can be kicked out if it is unresponsive to other members. It can also be kicked out if a network split occurs and it is in a subgroup that does not have a quorum. The former problem is the most likely to happen but the latter is also possible and we would like to address both of these with one solution. We would like to be able to have the kicked out process(es) perform normal shutdown but then go into a state where they attempt to reconnect to the distributed system, reinitialize the cache from the new persistent configuration service or from XML generated from the old cache and get back to a normal state.
This features poses serious challenges for Spring-based applications with GemFire objects (beans) injected into application components using Spring's container dependency injection.