RFR: 8376118: java/net/httpclient/StreamingBody.java fails intermittently on Windows [v4]

[Daniel Fuchs]

On Fri, 23 Jan 2026 10:51:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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:
> 
> ```java
> while (!stop) {
>     ForceGC.waitFor(() -> false, 500); // keep initiating GC
> }
> ```

We don't want this thread to keep on invoking GC in a busy loop - so I'd prefer to keep the current implementation that triggers the GC a few times. FWIW with the current setting (the gcinterval of 500ms passed to GCTrigger) and when the test doesn't encounter unexpected slow downs I see that the System.gc() is triggerred ~ 4 times in the course of the test execution. Since I wasn't able to reproduce the test error with that settings I'd say we reached the sweet spot :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29366#issuecomment-3791028660