Page History

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.

...

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.

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.