[
https://issues.apache.org/jira/browse/ZOOKEEPER-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126522#comment-13126522
]
Rakesh R commented on ZOOKEEPER-1225:
-------------------------------------
Following are some of the proposals. Any thoughts or better suggestion would be
appreciated.
*Proposal-1*
The main reason for the READY state transition is due to the multiple offer
(ephemeral node) creation, so the successive starts can have validation logic
by checking the existence of the ephemeral node which would be created during
the previous startup. If exists, return by giving warning msg.
The same logic can be applied to the stop() api also. Here if the ephemeral
node exists, it can allow the stop execution logic. Otherwise return by giving
warn msg.
*Proposal-2*
During startup, after the successful creation of offer it can set the ‘running’
flag to true and all the further startup will be validated.
During stop after the successful deletion of the offer it will reset the
‘running’ flag to false. If running==true, it can allow the stop otherwise just
give warn message.
*Note:* In the case if the LES is in FAILED state, then user has to explicitly
stop() the LES and starts again. So the previous offer(ephemeral will be
deleted).
I feel the +first approach+ is better, because let’s say if the zookeeper
session got expired, here the client node can create new zookeeper session and
simply starts.
But in the +second approach+ user has to explicitly stop() and then start().
Also when stopping it will fail since the session got expired and goes to
FAILED state transitions.
Thanks,
Rakesh
> Successive invocation of LeaderElectionSupport.start() will bring the ELECTED
> node to READY and cause no one in ELECTED state.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1225
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1225
> Project: ZooKeeper
> Issue Type: Bug
> Components: recipes
> Affects Versions: 3.3.3
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 3.5.0
>
>
> Presently there is no state validation for the start() api, so one can invoke
> multiple times consecutively. The second or further invocation will makes the
> client node to become 'READY' state transition. Because there is an offer
> already got created during the first invocation of the start() api, the
> second invocation again makeOffer() and after determination will be chosen as
> READY state transitions.
> This makes the situation with no 'ELECTED' nodes present and the client (or
> the user of the election recipe) will be indefinitely waiting for the
> 'ELECTED' node.
> Similarly, stop() api can be invoked and there is no state validation and
> this can dispatch unnecessary FAILED transition events.
> IMO, LES recipe can have validation logic to avoid the successive start() and
> stop() invocations.
--
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
