[ https://issues.apache.org/jira/browse/ZOOKEEPER-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15343034#comment-15343034 ]
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 1748630. +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/3234//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.6.0, 3.5.3 > > 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.3.4#6332)