Hi, I can see some potential problem with current Leader Election recipe. Before proceeding with changes to the existing recipe, I wanted to know the response from you all. Soon I will be publishing the algorithm/design doc to resolve the issues mentioned below. 1) Split-Brain problem: N/w disconnection can bring both Leader Election client nodes to be in ELECTED state. Current Leader Election f/w handles only 'NodeDeletion'. Consider the scenario where ELECTED and READY nodes are running. Say ELECTED node's n/w got failed and is "Disconnected" from ZooKeeper. But it will behave as ELECTED as it is not getting any events from the les framework. After sessiontimeout, node in READY state will be notified by 'NodeDeleted' event and will go to ELECTED state. Problem: Both the node becomes ELECTED, finally the user sees two master node and cause inconsistencies. 2) Ordered execution of the events is not guaranteed. User may not be able to determine which event occured first. IMO this design makes the usage of this recipe more complex and may result in erroneous client implementation. Consider the scenario where the user node is deteremined as READY, Now the f/w will dispatch the READY_START event to the user node and the watcher will get addded to the ELECTED node. Say just before dispatching the READY_COMPLETE event, ELECTED has become expired and 'NodeDeleted' event has reached to the f/w. In this case, there is high chance of dispatching the READY_COMPLETE during the leader determination time. Problem: Eventhough the f/w has the logical classification of events, it is not ensuring the ordered execution of logical events and leaves all the complexities to the user node/process. Sample Output: (It shows the wrong event handling mechanism) EventType -> START EventType -> OFFER_START EventType -> OFFER_COMPLETE EventType -> DETERMINE_START EventType -> DETERMINE_COMPLETE EventType -> READY_START EventType -> DETERMINE_START EventType -> ELETCED_START EventType -> READY_COMPLETE EventType -> ELECTED_COMPLETE -- Thanks, Rakesh.
