[ https://issues.apache.org/jira/browse/ZOOKEEPER-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717717#comment-13717717 ]
Flavio Junqueira commented on ZOOKEEPER-1733: --------------------------------------------- If you have cycles to look into it, please go ahead. There are other issues I'm looking into, so some help would be welcome. > 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 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira