[
https://issues.apache.org/jira/browse/HBASE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
