[
https://issues.apache.org/jira/browse/ZOOKEEPER-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785001#comment-13785001
]
Hudson commented on ZOOKEEPER-1733:
-----------------------------------
SUCCESS: Integrated in ZooKeeper-trunk #2077 (See
[https://builds.apache.org/job/ZooKeeper-trunk/2077/])
ZOOKEEPER-1733. FLETest#testLE is flaky on windows boxes (Jeffrey Zhong via
phunt) (phunt:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1528586)
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/FLETest.java
> FLETest#testLE is flaky on windows boxes
> ----------------------------------------
>
> Key: ZOOKEEPER-1733
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1733
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.4.5
> Reporter: Jeffrey Zhong
> Assignee: Jeffrey Zhong
> Fix For: 3.5.0
>
> Attachments: zookeeper-1733.patch, zookeeper-1733.patch
>
>
> FLETest#testLE fail intermittently on windows boxes. The reason is that in
> LEThread#run() we have:
> {code}
> if(leader == i){
> synchronized(finalObj){
> successCount++;
> if(successCount > (count/2))
> finalObj.notify();
> }
> break;
> }
> {code}
> Basically once we have a confirmed leader, the leader thread dies due to the
> "break" of while loop.
> While in the verification step, we check if the leader thread alive or not as
> following:
> {code}
> if(threads.get((int) leader).isAlive()){
> Assert.fail("Leader hasn't joined: " + leader);
> }
> {code}
> On windows boxes, the above verification step fails frequently because leader
> thread most likely already exits.
> Do we know why we have the leader alive verification step only lead thread
> can bump up successCount >= count/2?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
