[ https://issues.apache.org/jira/browse/ZOOKEEPER-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770361#comment-13770361 ]
Hadoop QA commented on ZOOKEEPER-1733: -------------------------------------- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12594008/zookeeper-1733.patch against trunk revision 1524275. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +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/1584//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1584//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1584//console This message is automatically generated. > 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 > > > 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