PlantUML |
---|
title This diagram shows a member (N) using a locator (L) discovering the Coordinator (C) and joining entity N entity L entity C N -> L : FindCoordinator(myId) note right : via tcp/ip L -> N : FindCoordinatorResponse(c) N -> C : JoinRequest note right : this and subsequent communications via UDP note right of C : ViewCreator thread processes request C -> N : PrepareView(c,l,n) N -> C : ack C -> L : PrepareView(c,l,n) L -> C : ack C -> N : InstallView(c,l,n) N -> C : ack note right of N continue startup after sending ack end note C -> L : InstallView(c,l,n) L -> C : ack |
The above diagram shows interaction with a Locator and the membership Coordinator during startup. The joining member first connects to all locators that it knows about and asks them for the ID of the current membership coordinator. Locators know about this because they, themselves, are part of the distributed system and receive all membership views. In the current implementation the method GMSJoinLeave.findCoordinator() is used to do this in the new member. The locators also tell the new member which membership view they are aware of so that the new member can choose the most recent, should the coordinator be in the process of establishing a new view. This is especially important if a new coordinator is in the process of taking control.
...
PlantUML |
---|
title This shows a member (M) leaving and another member (P) joining in the same view entity M entity C entity P M -> C : LeaveRequest C -> M : LeaveResponse note right of C : LeaveRequest is queued M -> M : done P -> C : JoinRequest note right of C JoinRequest is queued. View Creator wakes up and creates view {C,P} removing M end note C -> P : Prepare {C,P} P -> C : ack C -> P : Install {C,P} P -> C : ack note right of P: P processes view and completes Join |
Geode can handle simultaneous membership additions and removals. Join, Leave and Remove requests are queued in a list in GMSJoinLeave and are processed by a ViewCreator thread. It is the ViewCreator thread that creates and sends new membership views.
PlantUML |
---|
title This diagram shows two Locators starting up at the same time with no other members present. entity L1 entity L2 L1 -> L2 : FindCoordinator note right : via tcp/ip L2 -> L1 : FindCoordinatorResponse(registrants={L2,L1}) note right of L2 both members get {L1,L2} registrants and choose L1 as coordinator due to ID sort order end note L2 -> L1 : FindCoordinator L1 -> L2 : FindCoordinatorResponse(registrants={L1,L2}) note right of L2 : subsequent messaging is via UDP L2 -> L1 : JoinRequest L1 -> L1 : becomeCoordinator note right of L1 : L1 ViewCreator thread processes request L1 -> L2 : PrepareView(L1,L2) L2 -> L1 : ack L1 -> L2 : InstallView(L1,L2) L2 -> L1 : ack note right of L1 : L1 and L2 continue startup |
It's best to stagger the start-up of locators but Geode can handle simultaneous startup as well. GMSLocator maintains a collection of what it calls "registrants" who have contacted it requesting the ID of the current coordinator. If there is no coordinator it will respond with the collection of registrants and the processes that are trying to join will use this information to determine who is most likely to be chosen as membership coordinator. They will then send a JoinRequest to that process in hope that it will figure out that it should become coordinator and take action on the request.
In the above diagram we see L1 make the decision to become coordinator and create an initial membership view. Since it has received a JoinRequest from L2 it includes it in this initial view.