[
https://issues.apache.org/jira/browse/ZOOKEEPER-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125704#comment-13125704
]
Rakesh R commented on ZOOKEEPER-1209:
-------------------------------------
Hi folks,
I would like to point out one more difficulty in using the existing
‘LeaderElectionSupport' (LES) recipe.
*Ordered execution of the events is not guaranteed*. The f/w has the logical
classification of events (for ex: *_START, *_COMPLETE), but it is not ensuring
the execution order of these logical events. This makes the usage of the recipe
more complex and may result in erroneous client/user implementation.
*Scenario:*
Consider the scenario where the user node is determined as READY state, now the
LES f/w first dispatches the READY_START event to the user node and then
watcher will get added to the ELECTED node. Say just before dispatching the
READY_COMPLETE event, ELECTED has become expired or stopped. So the
'NodeDeleted' event will be notified to the f/w and will go to the leader
determination phase by dispatching the DETERMINE_START and DETERMINE_COMPLETE
events.
In this case, there is high chance of dispatching the READY_COMPLETE during the
leader determination time or even later.
+Following shows the sample output of Ready node events:+
START
OFFER_START
OFFER_COMPLETE
DETERMINE_START
DETERMINE_COMPLETE
READY_START
DETERMINE_START
DETERMINE_COMPLETE
ELECTED_START
READY_COMPLETE
ELECTED_COMPLETE
+*Proposal*+
The patch which I have uploaded contains the *‘LES-EventProcessor’* service and
this will help the recipe to ensure the ordered execution of the events.
Thanks,
Rakesh
> LeaderElection recipe doesn't handle the split-brain issue, n/w disconnection
> can bring both the client nodes to be in ELECTED
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1209
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1209
> Project: ZooKeeper
> Issue Type: Bug
> Components: recipes
> Affects Versions: 3.3.3
> Reporter: Rakesh R
> Assignee: Rakesh R
> Attachments: ZOOKEEPER-1209.patch
>
>
> *Case1-* N/w disconnection can bring both the client nodes to be in ELECTED
> state. Current LeaderElectionSupport(LES) 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
> LeaderElectionSupport(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 and finally the user sees two Master (ELECTED)
> node and cause inconsistencies.
> *Case2-* Also in this case, Let's say if user has started only one client
> node and becomes ELECTED. After sometime n/w has disconnected with the
> ZooKeeper server and the session got expired.
> *Problem:*
> Still the client node will be in the ELECTED state. After sometime if user
> has started the second client node. Again both the nodes becomes ELECTED.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
