[ https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549980#comment-13549980 ]
Hadoop QA commented on HBASE-7384: ---------------------------------- {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12564216/hbase-7384_2.4.patch against trunk revision . {color:green}+1 @author{color}. The patch does not contain any @author tags. {color:green}+1 tests included{color}. The patch appears to include 11 new or modified tests. {color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop 2.0 profile. {color:green}+1 javadoc{color}. The javadoc tool did not generate any warning messages. {color:green}+1 javac{color}. The applied patch does not increase the total number of javac compiler warnings. {color:green}+1 findbugs{color}. The patch does not introduce any new Findbugs (version 1.3.9) warnings. {color:green}+1 release audit{color}. The applied patch does not increase the total number of release audit warnings. {color:red}-1 lineLengths{color}. The patch introduces lines longer than 100 {color:red}-1 core tests{color}. The patch failed these unit tests: org.apache.hadoop.hbase.client.TestMultiParallel org.apache.hadoop.hbase.replication.TestReplicationWithCompression org.apache.hadoop.hbase.TestLocalHBaseCluster {color:red}-1 core zombie tests{color}. There are 1 zombie test(s): at org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup.testBalancerWithRackLocality(TestBalancerWithNodeGroup.java:220) Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3962//console This message is automatically generated. > Introducing waitForCondition function into test cases > ----------------------------------------------------- > > Key: HBASE-7384 > URL: https://issues.apache.org/jira/browse/HBASE-7384 > Project: HBase > Issue Type: Test > Components: test > Reporter: Jeffrey Zhong > Assignee: Jeffrey Zhong > Labels: test > Fix For: 0.96.0 > > Attachments: hbase-7384_1.0.patch, hbase-7384_2.4.patch, > hbase-7384.patch, Waiter.java > > > Recently I'm working on flaky test cases and found we have many places using > while loop and sleep to wait for a condition to be true. There are several > issues in existing ways: > 1) Many similar code doing the same thing > 2) When time out happens, different errors are reported without explicitly > indicating a time out situation > 3) When we want to increase the max timeout value to verify if a test case > fails due to a not-enough time out value, we have to recompile & redeploy code > I propose to create a waitForCondition function as a test utility function > like the following: > {code} > public interface WaitCheck { > public boolean Check() ; > } > public boolean waitForCondition(int timeOutInMilliSeconds, int > checkIntervalInMilliSeconds, WaitCheck s) > throws InterruptedException { > int multiplier = 1; > String multiplierProp = System.getProperty("extremeWaitMultiplier"); > if(multiplierProp != null) { > multiplier = Integer.parseInt(multiplierProp); > if(multiplier < 1) { > LOG.warn(String.format("Invalid extremeWaitMultiplier > property value:%s. is ignored.", multiplierProp)); > multiplier = 1; > } > } > int timeElapsed = 0; > while(timeElapsed < timeOutInMilliSeconds * multiplier) { > if(s.Check()) { > return true; > } > Thread.sleep(checkIntervalInMilliSeconds); > timeElapsed += checkIntervalInMilliSeconds; > } > assertTrue("WaitForCondition failed due to time out(" + > timeOutInMilliSeconds + " milliseconds expired)", > false); > return false; > } > {code} > By doing the above way, there are several advantages: > 1) Clearly report time out error when such situation happens > 2) Use System property extremeWaitMultiplier to increase max time out > dynamically for a quick verification > 3) Standardize current wait situations > Pleas let me know what your thoughts on this. > Thanks, > -Jeffrey -- 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