[
https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107255#comment-13107255
]
Benjamin Reed commented on ZOOKEEPER-1191:
------------------------------------------
good catch alex. wrt your patch. your problem is cur <= end: when cur == end,
you will do a wait(0), which means wait forever. it might also be good write a
common function and call that. something like: doSafeWaitForNewEpoch(Object
waitObj, milliSeconds)
> Synchronization issue - wait not in guarded block
> -------------------------------------------------
>
> Key: ZOOKEEPER-1191
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1191
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.0
> Reporter: Alexander Shraer
> Assignee: Alexander Shraer
> Priority: Minor
> Fix For: 3.4.0
>
> Attachments: zookeeper-1191.patch
>
>
> In Leader.java, getEpochToPropose() and waitForEpochAck() have the following
> code:
> if (readyToStart && verifier.containsQuorum(electingFollowers)) {
> electionFinished = true;
> electingFollowers.notifyAll();
> } else {
> electingFollowers.wait(self.getInitLimit()*self.getTickTime());
> if (waitingForNewEpoch) {
> throw new InterruptedException("Out of time to propose an epoch");
> }
> }
> In Java, the wait statement can wake up without being notified, interrupted,
> or timing out, a so-called spurious wakeup. So it should be guarded by a
> while loop with the condition we're waiting for.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
