[jira] [Updated] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-7384:
-
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
I just committed this. 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
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] [Updated] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-7384:
-
Attachment: hbase-7384_2.4.patch
Resubmit patch to incorporate Enis feedbacks.
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
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] [Updated] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-7384:
-
Attachment: hbase-7384.patch
This patch is a baby step towards on flaky tests. Most flaky tests I found
especially for cross platform tests are due to not long enough hard coded time
out values. It would be much more pleasant if we can easily identify premature
time out situations and adjust max time out values dynamically by a system
property according to different environment needs.
I migrated two test cases to use the new waitFor functions as an example. The
new waitFor function will fully benefit us after we migrate all old test cases
and use the new waitFor pattern for future test cases.
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
Attachments: 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] [Updated] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-7384:
-
Fix Version/s: 0.96.0
Labels: test (was: )
Status: Patch Available (was: Open)
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.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] [Updated] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-7384:
-
Attachment: hbase-7384_1.0.patch
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] [Updated] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-7384:
--
Summary: Introducing waitForCondition function into test cases (was:
Introduing waitForCondition function into test cases)
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
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] [Updated] (HBASE-7384) Introducing waitForCondition function into test cases
[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HBASE-7384:
--
Attachment: Waiter.java
In Oozie we've been using this pattern quite successfully. In case you are
interested, the attached file is a cannibalized version of that code removing
all Oozie deps.
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
