On Fri, 23 Jan 2026 10:51:04 GMT, Daniel Fuchs <[email protected]> wrote:
>> This test has been observed failing intermittently in the CI, either in
>> JTreg timeout, where the test passes successfully after the timeout has
>> fired but while the failure handlers are still executing, or with an
>> `SSLHandshakeException` caused by `"An established connection was aborted by
>> the software in your host machine"`.
>>
>> This test creates 500 clients and relies on the GC to close them (by
>> design), because it wants to catch bugs where clients would be GC'ed too
>> early. However, relying on the GC to close the clients can put pressure on
>> resource allocation on the machine, which we suspect is the cause for the
>> slow down and the test failures. @Michael-Mc-Mahon suggested we could try to
>> relieve the pressure by making explicit calls to `System.gc()`, in the hope
>> to reclaim the abandonned clients earlier.
>>
>> This changes implements the suggestion by making calls to `System.gc()` at
>> random interval from a separate thread, and converts the test to JUnit,
>> making it stop at the first failure (which otherwise has a frustrating
>> tendency to disappear in the JTreg Output Overflow).
>>
>> With that change, I have not been able to observe the test failing again.
>
> Daniel Fuchs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Review feedback
Hello Daniel, this looks OK to me. The GC trigger appears a slightly involved.
Maybe we could have just done the following in that GCTrigger thread:
while (!stop) {
ForceGC.waitFor(() -> false, 500); // keep initiating GC
}
-------------
Marked as reviewed by jpai (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/29366#pullrequestreview-3698003427
