THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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.
PlantUML |
---|
title state transitions for joining member
[*] -> Discovery
Discovery: search for coordinator
Discovery: using Locator service
Discovery -> Joining
Joining: join req sent to coordinator
Joining -> Member
Member: unique ID established
Member: membership view installed
Member -> [*] |
Simultaneous joins and leaves
...
PlantUML |
---|
title Details of concurrent startup of two locators when the locators are preferred as membership coordinators. This diagram focuses on the second locator, L2 end title hide footbox entity L1 #grey entity C entity L2 note right of L2 L1 and L2 have been killed. C detects loss and becomes coordinator. L1 and L2 are restarted simultaneously end note L1 -> C : JoinRequest C -> L1 : prepare view(coord=C,L1) L2 -> L1 : recover L1 --> L2 : old view + L1 note right of L2 L2 will try to join with L1 and then fall into findCoordinatorFromView end note L2 -> L1 : JoinRequest L1 -> L1 : queues JoinRequest from L2 C -> L1 : install view(coord=C,L1) note left: L1 is a member now L2 -> C : FindCoordinator note right: (sent via UDP) C --> L2 : response(coord=C) note right At this time C is still coordinator and will tell L2, who will try to join with it end note L1 -> C : prepare/install view(coord=L1,C) L2 -> C : JoinRequest C --> L2 : JoinResponse(coord=L1) note right C has received the deposing view from L1 and will respond to L2's JoinRequest with a response telling it that L1 is now coordinator end note L2 -> L2 : waits for response to initial JoinRequest L1 --> L2 : prepare/install view(coord=L1,C,L2) L2 -> L2 : continues startup |
...