-
Feature Request
-
Resolution: Done
-
Critical
-
7.3.0.CD18
-
None
This is follow up for JBEAP-18077. I would like to have documented findings of JBEAP-18077 discussion.
Initial text for discussion:
Scaling up multiple pods in cluster from 0 can lead to splited cluster.
This is inherent feature of the design of discovery in JGroups. In JGroups, discovery is the process by which a starting member locates an existing cluster coordinator. If no coordinator can be found within a given timeout, a starting node assumes that it is the first member and assumes coordinator status. When multiple pods start concurrently, they all make this assumption and we end up with multiple partitions that are later merged.
Splitted clusters can be avoided by:
- starting 1 pod and after that scale up to desired count of pods
- use StatefullSet which start pods in order (Eap Operator use StatefullSet under hood)
I propose to document it in chapter "8.7. Clustering" of book "Getting Started with JBoss EAP for OpenShift Container Platform"
Please takes that as proposal. Someone from developers involved in JBEAP-18077 discussion should define exact documentation text, e.g. pferraro or kwills@redhat.com
- is cloned by
-
JBEAP-23151 [7.4.z.GA] Document how to start EAP cluster safely
- Closed
- relates to
-
JBEAP-18077 (7.3.z) Scaling up multiple pods in parallel from 0 can lead to 2 coordinators
- Closed
-
JBEAP-22033 [GSS](7.4.z) Sessions do not expire in cluster after coordinator is killed
- Closed
-
JBEAP-22064 [GSS](7.3.z) WFLY-14868 - Sessions do not expire in cluster after coordinator is killed
- Closed
-
JBEAP-22506 [QE](7.4.z) Active sessions left in memory after cluster scale up/down in OCP
- Closed