Hey Lee, Your observation makes sense. To remove the timing (and OS network stack) sensitivity of the test, we should ideally get a hold on the internal server socket used by `HttpClient::available` (via reflecting on `NetworkClient::serverSocket`?), probe it ourselves, and then assert the `::available` outcome. I guess both `testClosedSocket()` and `testSocketWithUnconsumedData()` will need a similar amendment.
Would you be interested in contributing this fix? Cheers! On Sat, Aug 22, 2026 at 3:37 AM 이지원 <[email protected]> wrote: > JBS: https://bugs.openjdk.org/browse/JDK-8390064 > > For JDK-8390064, would test-only synchronization with client-side > observation of peer EOF be an appropriate way to avoid this test timing > race while retaining the existing one-shot available() assertion? > > In the reporter JTR, the second availability check in testClosedSocket > took the SocketTimeout path after the server-side accepted socket was > closed. HttpClient.available() then returned true, causing the existing > assertFalse(available()) to fail. > > HttpClient.available() performs a single probe with a 1 ms socket read > timeout. The server-side close can complete before the client observes EOF. > > I am not proposing any change to the production HttpClient behavior. The > test would first observe peer EOF on the client side, and then execute the > existing assertFalse(available()) exactly once. This is not intended to > turn the assertion into an "eventually false" check using polling or > retries. > > If this direction is appropriate, would test-only access to the underlying > client socket for this synchronization be acceptable? > > If not, is there an existing test hook you would prefer for this purpose, > or should this be addressed on the product side instead? > > Regards, > Lee Jiwon >
