[
https://issues.apache.org/jira/browse/HADOOP-20051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated HADOOP-20051:
------------------------------------
Labels: pull-request-available (was: )
> Fix race in TestRPC#testRpcMetrics
> ----------------------------------
>
> Key: HADOOP-20051
> URL: https://issues.apache.org/jira/browse/HADOOP-20051
> Project: Hadoop Common
> Issue Type: Bug
> Components: test
> Reporter: Jose Luis López
> Priority: Minor
> Labels: pull-request-available
>
> {{TestRPC#testRpcMetrics}} is intermittently flaky. It was seen in a Yetus
> run, failing once and passing on rerun:
> {noformat}
> TestRPC.testRpcMetrics:1355 Expected correct rpc response count ==> expected:
> <3000> but was: <2999>
> {noformat}
> The test makes 3000 RPCs and then immediately asserts that the RPC metric
> counters equal 3000. On the server, the handler calls
> {{Server.updateMetrics}} after the call has been processed and its response
> sent, so the client can receive the last response before that call's metrics
> are recorded. {{addRpcResponseTime}} is the last of the counters updated.
> The {{RpcLockWaitTimeAvgTime}} check after {{lockAndSleep}} has the same
> race, and fails with {{expected: <10000.0> but was: <0.0>}} when the metrics
> update is delayed. {{MutableStat.snapshot}} resets the interval average, so
> that check has to use the snapshot that saw the sample, not a new one taken
> after polling.
> The fix is test-only: wait with {{GenericTestUtils.waitFor}} before both sets
> of assertions, keeping the exact-equality checks. This is the same pattern as
> HADOOP-20048.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
