You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Alexander Shraer (JIRA)" <ji...@apache.org> on 2011/09/17 21:55:08 UTC

[jira] [Created] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

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


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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107526#comment-13107526 ] 

Benjamin Reed commented on ZOOKEEPER-1191:
------------------------------------------

+1 looks great alex. no test needed since the spurious wakeup cannot be induced. mahadev should i check this into 3.4.0? i'm thinking it should just go to trunk.

> 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-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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112342#comment-13112342 ] 

Benjamin Reed commented on ZOOKEEPER-1191:
------------------------------------------

Committed revision 1173949.

committed to trunk

thanx alex!

> 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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Alexander Shraer (JIRA)" <ji...@apache.org>.
    [ 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

        

[jira] [Updated] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Alexander Shraer (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Shraer updated ZOOKEEPER-1191:
----------------------------------------

    Attachment: zookeeper-1191-ver1.patch

> 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-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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
    [ 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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112347#comment-13112347 ] 

Mahadev konar commented on ZOOKEEPER-1191:
------------------------------------------

@Ben,
 yup just trunk should be fine. thanks for checking and apologize for my delayed response.

> 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

        

[jira] [Updated] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Alexander Shraer (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Shraer updated ZOOKEEPER-1191:
----------------------------------------

    Issue Type: Sub-task  (was: Bug)
        Parent: ZOOKEEPER-1192

> 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

        

[jira] [Updated] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Alexander Shraer (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Shraer updated ZOOKEEPER-1191:
----------------------------------------

    Attachment: zookeeper-1191.patch

> 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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107266#comment-13107266 ] 

Hadoop QA commented on ZOOKEEPER-1191:
--------------------------------------

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12494944/zookeeper-1191-ver1.patch
  against trunk revision 1171881.

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

    -1 tests included.  The patch doesn't appear to include any new or modified tests.
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac compiler warnings.

    +1 findbugs.  The patch does not introduce any new Findbugs (version 1.3.9) warnings.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

    +1 core tests.  The patch passed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/557//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/557//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/557//console

This message is automatically generated.

> 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-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

        

[jira] [Updated] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Reed updated ZOOKEEPER-1191:
-------------------------------------

    Fix Version/s:     (was: 3.4.0)
                   3.5.0

> 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.5.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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112516#comment-13112516 ] 

Hudson commented on ZOOKEEPER-1191:
-----------------------------------

Integrated in ZooKeeper-trunk #1311 (See [https://builds.apache.org/job/ZooKeeper-trunk/1311/])
    ZOOKEEPER-1191. Synchronization issue - wait not in guarded block
ZOOKEEPER-1192. Leader.waitForEpochAck() checks waitingForNewEpoch instead of checking electionFinished

breed : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1173949
Files : 
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/Leader.java
* /zookeeper/trunk/src/java/test/org/apache/zookeeper/server/quorum/Zab1_0Test.java


> 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

        

[jira] [Commented] (ZOOKEEPER-1191) Synchronization issue - wait not in guarded block

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107243#comment-13107243 ] 

Hadoop QA commented on ZOOKEEPER-1191:
--------------------------------------

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12494940/zookeeper-1191.patch
  against trunk revision 1171881.

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

    -1 tests included.  The patch doesn't appear to include any new or modified tests.
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac compiler warnings.

    +1 findbugs.  The patch does not introduce any new Findbugs (version 1.3.9) warnings.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

    -1 core tests.  The patch failed core unit tests.

    +1 contrib tests.  The patch passed contrib unit tests.

Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/556//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/556//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/556//console

This message is automatically generated.

> 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