[
https://issues.apache.org/jira/browse/BIGTOP-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465931#comment-13465931
]
Johnny Zhang commented on BIGTOP-721:
-------------------------------------
of course, for case daemon status doesn't match expected by 3rd try, test will
record the failure as usual
{noformat}
service hadoop-yarn-proxyserver status
__EOT__
12/09/28 14:17:33 TRACE shell.Shell: return: 1
12/09/28 14:17:33 TRACE shell.Shell:
<stdout>
Hadoop proxyserver is dead and pid file exists ... failed!
</stdout>
12/09/28 14:17:36 TRACE shell.Shell: /bin/bash -s << __EOT__
service hadoop-yarn-proxyserver status
__EOT__
12/09/28 14:17:36 TRACE shell.Shell: return: 1
12/09/28 14:17:36 TRACE shell.Shell:
<stdout>
Hadoop proxyserver is dead and pid file exists ... failed!
</stdout>
12/09/28 14:17:39 TRACE shell.Shell: /bin/bash -s << __EOT__
service hadoop-yarn-proxyserver status
__EOT__
12/09/28 14:17:39 TRACE shell.Shell: return: 1
12/09/28 14:17:39 TRACE shell.Shell:
<stdout>
Hadoop proxyserver is dead and pid file exists ... failed!
{noformat}
I have been tested both the positive and negative case already!
> improve the package daemon status check, check twice by some delay if status
> doesn't match expected value
> ---------------------------------------------------------------------------------------------------------
>
> Key: BIGTOP-721
> URL: https://issues.apache.org/jira/browse/BIGTOP-721
> Project: Bigtop
> Issue Type: Bug
> Components: Tests
> Affects Versions: 0.5.0
> Reporter: Johnny Zhang
> Assignee: Johnny Zhang
> Priority: Critical
> Fix For: 0.5.0
>
> Attachments: BIGTOP_721.txt
>
>
> the current package test check the daemon can be correctly started, stopped,
> restarted and so on. It first changes the daemon status (start it, or stop
> it), then sleep 3001, then use function checkThat to check if the daemon
> status satisfy the matcher.
> However, there is a case that daemon status update speed is slightly
> different: some daemon status change a little bit slower than others. In this
> case, we want the test can give a delay and check the daemon status again if
> it doesn't match the matcher at the first place.
> Example is:
> {noformat}
> service flume-ng-agent start
> __EOT__
> 12/09/28 14:10:19 TRACE shell.Shell:
> <stdout>
> Flume NG agent is not running..failed
> Starting Flume NG agent daemon (flume-ng-agent): ..done
> </stdout>
> 12/09/28 14:10:22 TRACE shell.Shell: /bin/bash -s << __EOT__
> service flume-ng-agent status
> __EOT__
> 12/09/28 14:10:22 TRACE shell.Shell: return: 3
> 12/09/28 14:10:22 TRACE shell.Shell:
> <stdout>
> Flume NG agent is not running..failed
> </stdout>
> 12/09/28 14:10:25 TRACE shell.Shell: /bin/bash -s << __EOT__
> service flume-ng-agent status
> __EOT__
> 12/09/28 14:10:25 TRACE shell.Shell:
> <stdout>
> Flume NG agent is running..done
> {noformat}
> in above example (real case) is in SLES11, the flume-ng-agent daemon status
> update is a little bit slower, after sleep 3001, the daemon doesn't shown as
> "running" yet, then we give another 3001 delay and check again, and it is
> shown as "running".
--
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
