[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235474#comment-13235474
 ] 

Rakesh R commented on ZOOKEEPER-1225:
-------------------------------------

Hi Flavio, Thanks for the interest. Yeah, here the determineElectionStatus() is 
judging with the recently created ephemeral node and updating its status 
accordingly.

As you suggested, LEStrategy would either consider the first one or not to 
allow multiple znode creation on start(). Anyway in the first case, its 
ignoring all the subsequent znodes and is having no extra logic with these 
znodes. IMO, better option would be restricts the multiple invocations & 
creation of znodes on start(). Also the recipe would be able to avoid the 
multiple/duplicate dispatchEvents.
                
> 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
>
>         Attachments: ZOOKEEPER-1225.patch
>
>
> 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

        

Reply via email to