[
https://issues.apache.org/jira/browse/HADOOP-20051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139280#comment-18139280
]
ASF GitHub Bot commented on HADOOP-20051:
-----------------------------------------
joseluisll opened a new pull request, #8952:
URL: https://github.com/apache/hadoop/pull/8952
### Description of PR
The handler updates the RPC metrics after sending the response, so the
client can see the last response before its metrics are recorded. Wait for the
counters before asserting on them, including the lock wait average after
lockAndSleep, which uses the snapshot that saw the sample because a snapshot
resets that average.
### How was this patch tested?
The changed modules' tests, run by the Yetus precommit and the fork's CI on
this branch.
### For code changes:
- [x] Does the title of this PR start with the corresponding JIRA issue id?
- [ ] Object storage: not applicable, no object store integration touched.
- [ ] If adding new dependencies to the code: not applicable, no new
dependency.
- [ ] If applicable, have you updated the LICENSE files: not applicable.
### AI Tooling
If an AI tool was used:
- [x] The PR includes the phrase "Contains content generated by <tool>"
where <tool> is the name of the AI tool used.
- [x] My use of AI contributions follows the ASF legal policy
https://www.apache.org/legal/generative-tooling.html
Contains content generated by Claude Code.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
> 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
>
> {{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]
