On Wed, 5 Nov 2025 12:13:42 GMT, Daniel Fuchs <[email protected]> wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java >> line 391: >> >>> 389: // Ensure that the connection is closed or returned to the >>> pool >>> 390: exch.nullBody(response, throwable); >>> 391: }); >> >> @dfuch, I've introduced this improvement against 204s, which you internally >> tipped me, in 480349b672e. Though I could not come up with a way to decently >> test this. Any suggestions? > > That's probably not testable. In case of nullBody() the CF will be > immediately completed anyway - so the only thing you'd risk at this point is > completing exceptionally a CF that was already completed with no observable > result. > Cancelling the timer there is "just" bookeeping - making sure we don't keep > timers in the queue when they're no longer needed (which is important too - > but there'd be no obvious way to test that, short of exposing the timer queue > to the test). A whitebox might be able to do that but you'd probably have to > add some additional accessors in the product code for testing purposes. > > FWIW see > https://github.com/openjdk/jdk/blob/master/test/jdk/java/net/httpclient/access/java.net.http/jdk/internal/net/http/Http3ConnectionAccess.java > and the place where it's used: > https://github.com/openjdk/jdk/blob/3e3822ad7eadbb3d86a3b94a6bd858f8c8ef9364/test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java#L120 > > You might be able to add a couple package-level accessors methods to > `HttpClientImpl` to get at the information you need and add your own accessor > class (similar to Http3ConnectionAccess.java) in the access library, and then > use that within your test. If you do so please add a // comment to explain > that the new methods are used by tests. I'm not very keen on hooking into internals, but I guess there is no other way. Implemented as suggested in 4eac3af5074. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2498717132
