[ https://issues.apache.org/jira/browse/ZOOKEEPER-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Nauroth updated ZOOKEEPER-1225: ------------------------------------- Fix Version/s: (was: 3.5.2) 3.5.3 > 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)