[Please respond to `[email protected]`.] The implementation you proposed sounds good. Note that for the `testSocketWithUnconsumedData()` case, once `serverSocket.getInputStream().read()` returns anything `>= 0`, where `serverSocket` is extracted via `privateLookupIn`, you can proceed with the existing `assertFalse(infra.available(), ...)` check. AFAIU, that is what you propose as well.
Please try to stick to the coding style present in the file, and keep your change set as minimal as possible. I will keep the JBS issue assigned to me. We will follow a similar route to the one you had in 8308183: Add a small ServerSocket based test to verify the fix <https://github.com/openjdk/jdk/pull/32209>. Quoting from the OpenJDK Developers' Guide <https://openjdk.org/guide/#jbs---jdk-bug-system>: *"To get write access you need to be registered in the OpenJDK Census by becoming, for instance, an Author in an OpenJDK Project."* On Tue, Aug 25, 2026 at 4:10 PM 이지원 <[email protected]> wrote: > Hello Volkan, > > Yes, I'd be interested in contributing the fix. > > I confirmed that the raw socket can be accessed by extending the > test's existing `privateLookupIn` approach to > `NetworkClient::serverSocket`. I haven't settled on that as the final > implementation choice yet, but it is feasible with the current test > setup. > > For `testClosedSocket()`, I'm planning to wait until EOF is observable > on the underlying socket before calling `HttpClient::available`. For > `testSocketWithUnconsumedData()`, I'm planning to wait until the > underlying socket reports pending data with a non-consuming > `available() > 0` check, then keep the existing > `HttpClient::available` assertion as the actual probe. > > The barriers differ because reading EOF does not consume application > data, while reading in the stale-data case would consume the very data > that the existing `HttpClient::available` assertion is meant to > detect. > > Would you prefer to keep the JBS issue assigned to you, or should it > be assigned to me for the contribution? > > Thanks, > Jiwon Lee > > > 2026년 8월 25일 (화) 오후 9:26, Volkan Yazıcı <[email protected]>님이 작성: > > > > 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 >
