yandrey321 opened a new pull request, #11876:
URL: https://github.com/apache/ozone/pull/11876
## What changes were proposed in this pull request?
**Problem.** `evictionDrivenCloseDoesNotSerializeAcquisition` fails
intermittently in CI ("expected less than 40, was
41"). It divided the wall time of the whole run by the number of evictions
and required less than 40 ms per close.
The bound guards against HDDS-15849's regression, a graceful channel
shutdown that sleeps at least 100 ms in every
`XceiverClientGrpc.close()`.
Since HDDS-16812, the manager closes evicted clients one after another on a
single background thread, and the test
waits for that queue to drain. So the measured time is now mostly creating
64 gRPC clients plus running 63 closes in
turn on one thread. Locally that is 3–4 ms per eviction, of which `close()`
itself is under 1 ms. A loaded CI runner
is about 10 times slower at creating clients and scheduling threads, which
reaches the 40 ms bound without any change
in `close()`.
**Implementation idea.** Time each eviction-driven `close()` of the real
`XceiverClientGrpc` and assert on the median.
The test keeps the real `XceiverClientManager`, the real eviction-driven
closes and the 8-thread churn. Its
`newClient()` override creates the same `XceiverClientGrpc` the manager
would, with `close()` wrapped to record how
long it took. The test then requires a median below 50 ms.
**Key decisions.**
- **The median of the closes themselves, not the wall clock.** The
regression puts every close over 100 ms, so the
median too. With the fix, the median is under a millisecond, and a slow
machine doesn't move it: client creation
and the queueing on the close thread are no longer measured.
- **Only real closes are recorded.** `close()` is idempotent; a repeated
call returns at once and would pull the
median down.
- **Every evicted client must have been closed.** The test also checks that
at least as many closes were timed as
evictions happened.
- **No production code changes.** Whether eviction-driven closes run off the
caller thread and outside the cache lock
stays covered by `slowCloseOfEvictedClientDoesNotBlockCaller`.
Generated-by: Claude Code (Claude Opus 5.5)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-17634
## How was this patch tested?
- **The test itself, 3 runs:** passes; median close 0 ms, maximum 0–1 ms.
- **Regression check:** with `XceiverClientGrpc.close()` sleeping 100 ms, as
before HDDS-15849, the test fails (median
107 ms).
- **Slow-machine check:** with `XceiverClientGrpc.connect()` sleeping 60 ms
per client, the new test passes (median
close 0 ms). The old test fails at 73 ms per close, which reproduces the
CI failure.
- **The other tests in the class**
(`slowCloseOfEvictedClientDoesNotBlockCaller`,
`managerClosesCachedClientsInParallel`) pass; checkstyle reports no violations.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
