[jira] [Commented] (ZOOKEEPER-1225) Successive invocation of LeaderElectionSupport.start() will bring the ELECTED node to READY and cause no one in ELECTED state.

["Hadoop QA (JIRA)" <ji...@apache.org>]

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

Hadoop QA commented on ZOOKEEPER-1225:
--------------------------------------

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12498880/ZOOKEEPER-1225.patch
  against trunk revision 1615240.

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 3 new or modified tests.

    -1 patch.  The patch command could not apply the patch.

Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2260//console

This message is automatically generated.

> 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.1
>
>         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 was sent by Atlassian JIRA
(v6.2#6252)