JDK-8368824 : Multiple httpclient tests pass and then time out on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 26
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • Submitted: 2025-09-28
  • Updated: 2025-10-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8260555 - Change the default TIMEOUT_FACTOR from 4 to 1
Relates :  
JDK-8368514 - TLS stateless session ticket decryption fails on some providers
Relates :  
JDK-8367133 - DTLS: fragmentation of Finished message results in handshake failure
Description
The following tests failed in our tier 7 CI run for two cycles and then seem to have been fixed (see linked issues for candidate fixes):

java/net/httpclient/ThrowingSubscribersAsInputStream.java
java/net/httpclient/ThrowingSubscribersAsInputStreamAsync.java
java/net/httpclient/ThrowingSubscribersAsLimiting.java
java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java
java/net/httpclient/ThrowingSubscribersAsLines.java
java/net/httpclient/ThrowingSubscribersAsLinesAsync.java
java/net/httpclient/ThrowingSubscribersAsString.java
java/net/httpclient/ThrowingSubscribersAsStringAsync.java
java/net/httpclient/http3/H3ErrorHandlingTest.java
java/net/httpclient/http3/H3StopSendingTest.java

Sample failure:

DEBUG: [pool-1-thread-5] [139s 717ms] H3(QuicConnection(HttpClientImpl(1), QuicClientConnection(22))) aborting dispatch: java.io.IOException: QUIC endpoint closed - no error java.io.IOException: QUIC endpoint closed - no error
DEBUG: [Thread(QuicSelector(HttpClientImpl(1)))] [139s 717ms] QuicSelector(HttpClientImpl(1)) QuicTimerQueue: newDeadline: not scheduled (Deadline.MAX)no event scheduled
java.io.IOException: QUIC endpoint closed - no error
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:129)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.<init>(TerminationCause.java:56)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause$SilentTermination.<init>(TerminationCause.java:203)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.forSilentTermination(TerminationCause.java:96)
	at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.silentTerminateConnection(QuicEndpoint.java:1277)
	at java.net.http/jdk.internal.net.http.quic.QuicEndpoint.close(QuicEndpoint.java:1347)
	at java.net.http/jdk.internal.net.http.quic.QuicClient.closeEndpoint(QuicClient.java:476)
	at java.net.http/jdk.internal.net.http.quic.QuicClient.close(QuicClient.java:469)
	at java.net.http/jdk.internal.net.http.Http3ClientImpl.close(Http3ClientImpl.java:765)
	at java.net.http/jdk.internal.net.http.Http3ClientImpl.stop(Http3ClientImpl.java:796)
	at java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:550)
	at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1297)
	at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1499)
DEBUG: [HttpClient-1-SelectorManager] [139s 717ms] QuicSelector(HttpClientImpl(1)) closing
Comments
I have not started any investigation on this one. These tests are running with the default timeout factor of 1 in tier7, so I was for JDK-8369491 to be integrated. Now that it has been integrated into mainline, the timeout factor is back to 4. I'll keep a watch on these tests in tier7 in our CI and if they continue to fail then I'll take a deeper look.
16-10-2025
This looks like another symptom of the aftermath of switching to timeoutFactor=1. I see in one of the logs: -J-Dtest.timeout.factor=1.0 \\ I believe the exception is a red herring - probably due to some too eager logging of stack traces when closing idle connections at the time the client is stopped. The test I was looking at appears to have successfuly completed, but was later interrupted in jtreg timeout. ``` ========================= [175 s, 189 ms, 517920 ns] Created 5 servers and 121 clients ========================= config AbstractThrowingSubscribers.printFailedTests(org.testng.TestRunner@5d51ed81): success [0ms] [175 s, 336 ms, 689980 ns] teardown Waiting for HTTP operations to terminate... gracedelay: 5000 ms, iterations: 500, wait/iteration: 10ms No outstanding HTTP operations remaining after 3/500 iterations and 30/5000 ms, (wait/iteration 10 ms) PASSED: No outstanding operations or unreleased resources found in 121 clients in 1923 ms Http1TestServer: stop Http1TestServer: stop Http2TestServerImpl: stop Http2TestServerImpl: stop Http2TestServerImpl: stop [177 s, 653 ms, 108710 ns] teardown done config AbstractThrowingSubscribers.teardown(): success [0ms] =============================================== java/net/httpclient/ThrowingSubscribersAsString.java Total tests run: 40, Passes: 40, Failures: 0, Skips: 0 =============================================== ```
02-10-2025