[
https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107587#comment-13107587
]
Alexander Shraer commented on ZOOKEEPER-1191:
---------------------------------------------
Thanks, Ben! I now found another related issue so I'm converting this to a
sub-task of ZK-1192, and submitting a new patch for both bugs in ZK-1192 (the
patch I attached above shouldn't be used).
> Synchronization issue - wait not in guarded block
> -------------------------------------------------
>
> Key: ZOOKEEPER-1191
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1191
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: server
> Affects Versions: 3.4.0
> Reporter: Alexander Shraer
> Assignee: Alexander Shraer
> Priority: Minor
> Fix For: 3.4.0
>
> Attachments: zookeeper-1191-ver1.patch, 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
