-
Bug
-
Resolution: Done
-
Major
-
7.0.0.GA
-
None
If the joiner has the correct view id, but the current status is
RECOVERING_CLUSTER, we should wait for the cluster status recovery to
finish before adding the new member.
We are currently not doing that, so the new member could be erased by the status recovery process that's in progress. This can happen if the coordinator joiner already had been a member of the JGroups cluster for some time, and there's no view change when they actually start their caches (exactly the scenario in ConcurrentStartTest).
- causes
-
ISPN-5495 ConcurrentStartTest.testConcurrentStart random failures
- Closed
- clones
-
ISPN-6235 ClusterTopologyManagerImpl join during cluster status recovery
- Closed
- is incorporated by
-
ISPN-6433 Backport to 8.1.x branch
- Closed
-
JBEAP-4124 Upgrade to Infinispan 8.1.4.Final
- Closed