You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This diagram shows a member (N) using a locator (L) discovering the Coordinator (C) and joining N N L L C C FindCoordinator(myId) via tcp/ip FindCoordinatorResponse(c) JoinRequest this and subsequent communications via UDP ViewCreator thread processes request PrepareView(c,l,n) ack PrepareView(c,l,n) ack InstallView(c,l,n) ack continue startup aftersending ack InstallView(c,l,n) 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.

Once the coordinator's ID is known the new member sends a JoinRequest to it.  The new member will know that it has been accepted when it receives a membership view containing its ID.  At this point it sets the view-ID of its identifiers.  The view-ID, in combination with its IP address and membership port (the UDP port used by JGroups) uniquely identifies this member.

  This shows a member (M) leaving and another member (P) joining in the same view M M C C P P LeaveRequest LeaveResponse LeaveRequest is queued done JoinRequest JoinRequest is queued.View Creator wakes up andcreates view {C,P} removing M Prepare {C,P} ack Install {C,P} ack 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.

  This diagram shows two Locators starting up at the same time with no other members present. L1 L1 L2 L2 FindCoordinator via tcp/ip FindCoordinatorResponse(registrants={L2,L1}) both members get {L1,L2} registrants and chooseL1 as coordinator due to ID sort order FindCoordinator FindCoordinatorResponse(registrants={L1,L2}) subsequent messaging is via UDP JoinRequest becomeCoordinator L1 ViewCreator thread processes request PrepareView(L1,L2) ack InstallView(L1,L2) ack 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.

 

 

  • No labels