[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551891#comment-13551891
]
Hudson commented on HBASE-7384:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #345 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/345/])
HBASE-7384 Introducing waitForCondition function into test cases (Jeffrey
Zhong) (Revision 1432358)
Result = FAILURE
enis :
Files :
* /hbase/trunk/hbase-common/src/test/java/org/apache/hadoop/hbase/Waiter.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestSplitLogManager.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitLogWorker.java
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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551799#comment-13551799
]
Hudson commented on HBASE-7384:
---
Integrated in HBase-TRUNK #3735 (See
[https://builds.apache.org/job/HBase-TRUNK/3735/])
HBASE-7384 Introducing waitForCondition function into test cases (Jeffrey
Zhong) (Revision 1432358)
Result = FAILURE
enis :
Files :
* /hbase/trunk/hbase-common/src/test/java/org/apache/hadoop/hbase/Waiter.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestSplitLogManager.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitLogWorker.java
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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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;
}
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13547298#comment-13547298
]
Enis Soztutar commented on HBASE-7384:
--
Some comments below:
1. Can you change:
{code}
+ public static final String TEST_WAITFOR_RATIO_PROP = test.waitfor.ratio;
{code}
to hbase.test.wait.for.ratio (same for WAIT_FOR_RATIO_DEFAULT)
2. Waiter does not have InterfaceAudience annotation. Can you add
@InterfaceAudience.Private
3. For Predicate, can we instead use com.google.collections.Predicate, or do we
need the exception in method signature. If we want to allow
Predicate.evaluate() to throw exceptions, then we want to bubble this up to the
waitFor(), and eventually to the test which called waitFor(). We can define the
exception type as a generic, and allow for waitFor to throw this as well. Smt
like:
{code}
class PredicateE { boolean evaluate() throws E }
public static E long waitFor(long timeout, long interval, PredicateE
predicate) throws E
{code}
4.Predicate should not be annotated Public.
5. Why are we evaluating the predicate on interruption?
6. Can you get the hbase.test.wait.for.ratio from configuration instead of
system property. We can either get the configuration from the method
definitions, or maybe hook into HBaseTestingUtility.
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.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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540604#comment-13540604
]
Ted Yu commented on HBASE-7384:
---
Putting patch on review board would make reviewing easier.
{code}
+ * A class that provides a standard waitFor implementation pattern
{code}
Remove 'implementation' above.
{code}
+public abstract class Waiter {
{code}
I don't see abstract method inside Waiter. The class shouldn't be abstract.
{code}
+ private static final Log LOG = LogFactory.getLog(Bytes.class);
{code}
Fix class name above.
{code}
+ public static final String TEST_WAITFOR_RATIO_PROP = test.waitfor.ratio;
{code}
Please explain the meaning of the ratio.
{code}
+ * {@link #waitFor(long, long, Predicate)} and {@link #waitFor(long, long,
boolean, Predicate)} method
{code}
Wrap long line above. 'method' - 'methods'
{code}
+ * This is useful when running tests in slow machines for tests that are
time sensitive.
{code}
Rephrase the above as 'This is useful when running time sensitive tests on slow
machines'
Currently setWaitForRatio() is not called. In what circumstance would it be
used ?
{code}
+ * Returns the 'wait for ratio' used in the {@link #sleep(long)}, {@link
#waitFor(int, Predicate)}
+ * and {@link #waitFor(int, boolean, Predicate)} methods for the current
test class. p/ This is
{code}
I think the parameter types for the two waitFor() methods are wrong.
{code}
+ * useful when running tests in slow machines for tests that are time
sensitive. p/ The default
{code}
Suggest similar rephrase for above.
{code}
+ * value is obtained from the Java System property
codetest.wait.for.ratio/code which defaults
{code}
The property name is different from the value for TEST_WAITFOR_RATIO_PROP
{code}
{code}
+ * Makes the current thread sleep for the specified number of milliseconds.
{code}
The above description is not accurate, please mention the role of WaitForRatio
More reviews to follow
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.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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540613#comment-13540613
]
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/12562544/hbase-7384_1.0.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 8 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 2
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:green}+1 core tests{color}. The patch passed unit tests in .
{color:red}-1 core zombie tests{color}. There are 2 zombie test(s):
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3740//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.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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540729#comment-13540729
]
Jeffrey Zhong commented on HBASE-7384:
--
Thanks Ted for reviewing. I've incorporated your feedbacks into a new patch and
submitted it into review board for easily reviewing.
https://reviews.apache.org/r/8772/
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.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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540769#comment-13540769
]
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/12562544/hbase-7384_1.0.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 8 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 2
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.replication.regionserver.TestReplicationSink
org.apache.hadoop.hbase.coprocessor.TestRegionObserverInterface
org.apache.hadoop.hbase.rest.TestStatusResource
org.apache.hadoop.hbase.rest.TestSchemaResource
org.apache.hadoop.hbase.client.TestAdmin
org.apache.hadoop.hbase.coprocessor.TestCoprocessorEndpoint
org.apache.hadoop.hbase.master.TestMasterTransitions
org.apache.hadoop.hbase.replication.TestReplicationSource
org.apache.hadoop.hbase.master.TestAssignmentManagerOnCluster
org.apache.hadoop.hbase.rest.TestScannersWithFilters
org.apache.hadoop.hbase.regionserver.TestServerCustomProtocol
org.apache.hadoop.hbase.master.TestMasterRestartAfterDisablingTable
org.apache.hadoop.hbase.master.TestMaster
org.apache.hadoop.hbase.util.TestIdLock
org.apache.hadoop.hbase.client.TestShell
org.apache.hadoop.hbase.master.TestMasterNoCluster
org.apache.hadoop.hbase.regionserver.TestClusterId
org.apache.hadoop.hbase.coprocessor.TestMasterObserver
org.apache.hadoop.hbase.regionserver.wal.TestHLogSplitCompressed
org.apache.hadoop.hbase.master.TestDistributedLogSplitting
org.apache.hadoop.hbase.regionserver.wal.TestWALReplay
org.apache.hadoop.hbase.zookeeper.TestZooKeeperACL
org.apache.hadoop.hbase.filter.TestColumnRangeFilter
org.apache.hadoop.hbase.coprocessor.TestWALObserver
org.apache.hadoop.hbase.io.hfile.TestHFileBlock
org.apache.hadoop.hbase.security.access.TestAccessControlFilter
org.apache.hadoop.hbase.TestLocalHBaseCluster
org.apache.hadoop.hbase.util.TestFSUtils
org.apache.hadoop.hbase.TestFullLogReconstruction
org.apache.hadoop.hbase.coprocessor.TestRegionObserverBypass
org.apache.hadoop.hbase.mapreduce.TestRowCounter
org.apache.hadoop.hbase.mapreduce.TestMultithreadedTableMapper
org.apache.hadoop.hbase.security.token.TestZKSecretWatcher
org.apache.hadoop.hbase.replication.TestReplication
org.apache.hadoop.hbase.TestAcidGuarantees
org.apache.hadoop.hbase.security.access.TestZKPermissionsWatcher
org.apache.hadoop.hbase.regionserver.wal.TestLogRollAbort
org.apache.hadoop.hbase.master.handler.TestTableDeleteFamilyHandler
org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildHole
org.apache.hadoop.hbase.master.TestMasterFileSystem
org.apache.hadoop.hbase.io.encoding.TestUpgradeFromHFileV1ToEncoding
org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort
org.apache.hadoop.hbase.master.TestMasterFailover
org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster
org.apache.hadoop.hbase.mapreduce.TestImportExport
org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit
org.apache.hadoop.hbase.master.TestZKBasedOpenCloseRegion
org.apache.hadoop.hbase.filter.TestFilterWithScanLimits
org.apache.hadoop.hbase.catalog.TestMetaReaderEditor
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540774#comment-13540774
]
Ted Yu commented on HBASE-7384:
---
The above test failures were due to:
{code}
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
{code}
See
https://builds.apache.org/job/PreCommit-HBASE-Build/3744//testReport/org.apache.hadoop.hbase/TestAcidGuarantees/testGetAtomicity/
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.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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540276#comment-13540276
]
Enis Soztutar commented on HBASE-7384:
--
This tool is useful, but as Nick pointed out, we should really be using
CountDownLatch'es for test synchronization. The problem, however, is that most
of the time, the latch release should happen from the main code, and there is
no generic injection mechanism yet to do this from the tests cleanly. For
example the patch in HBASE-5494 introduces a class called InjectionHandler for
doing this, but not sure if it is the best interface.
Above is out of the scope for this isssue, but I think we should keep that in
mind.
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.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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536460#comment-13536460
]
Nick Dimiduk commented on HBASE-7384:
-
I did something similar in HBASE-7243. It's a notification system with a
configurable interrupt, based loosely on [this
post|http://googletesting.blogspot.com/2008/08/tott-sleeping-synchronization.html]
from the Google Testing blog. Whatever we use, it would be great to have
something that's dependable and consistently implemented throughout!
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
Attachments: 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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536693#comment-13536693
]
Jeffrey Zhong commented on HBASE-7384:
--
Thanks a lot for everyone's input. Push model based waitFor(as suggested by
Nick) is ideal while it isn't always possible to implement and sometimes also
require production code changes.
After checking with Alejandro's attachment Waiter.java, I think it's very
close to what I have in mind. I'll come up a version based on the Waiter.java.
The advantage to have a generic waitFor function with dynamically config
capability can allow us to set different max time out value for different test
environments(like different OS, virtual machine setting etc.) without keeping
changing max timeout values to fit all possible slowest environments.
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
Attachments: 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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13535512#comment-13535512
]
Jeffrey Zhong commented on HBASE-7384:
--
Thanks!
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
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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13535552#comment-13535552
]
Todd Lipcon commented on HBASE-7384:
Hadoop Common has GenericTestUtils#waitFor which basically does this (though
not with a backoff).
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
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
[jira] [Commented] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13535594#comment-13535594
]
Jeffrey Zhong commented on HBASE-7384:
--
Thanks Todd for pointing the GenericTestUtils#waitFor out. It almost does the
thing I proposed in the ticket. Surprisingly we don't use it. While the only
thing it misses is the capability to dynamically increase max time out value to
quickly verify a not-enough time out situation without recompile deploy. If
you think the dynamically increasing time out capability is needed, I can
create a HBase waitFor version supporting the capability and internally calling
the hadoop common GenericTestUtils#waitFor.
Thanks,
-Jeffrey
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
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
