Bug ID: JDK-8349910 Implement JEP 517: HTTP/3 for the HTTP Client API

JDK 26
26 b17Fixed

> I would like to open a sub-task of JDK-8368739 and add exceptions for AIX, do you think that's fine ? In the mid/longer term maybe I can get some info from IBM if it is possible to add some config tweaks/machine settings to get it working on AIX. [~mbaesken] that sounds fine. I'd support adding a separate jtreg comment section for AIX and alter the problematic `@run` to use whatever max PDU works by default for AIX on the loopback. That might require a bit of testing to figure that out. Feel free to alter the parameters on AIX to make it pass consistently with the default system configuration on that OS.
03-10-2025
> The jtr file of the failure will have the exact detail about which test action failed. Would you be able to share that file? In any case, please create a separate JBS issue with the details so that the jtr can be attached to that. Hi [~jpai] and [~dfuchs] I created JDK-8368739 and added the jtr files there . > We may need to make an exception for AIX there. Unless there's some configuration tweak you could make on the CI machines to allow 16k MTU on the loopback? (Note - it's 16336 to make room for the IP headers) I would like to open a sub-task of JDK-8368739 and add exceptions for AIX, do you think that's fine ? In the mid/longer term maybe I can get some info from IBM if it is possible to add some config tweaks/machine settings to get it working on AIX.
26-09-2025
My guess is that the defaultMTU=16336 is what is causing problems on AIX. On all other platforms where we tested 16k seems acceptable by default on the loopback. Typically Datagrams that are too big can be dropped by the system/interface, there may be some system configuration that would allow to tweak that. We may need to make an exception for AIX there. Unless there's some configuration tweak you could make on the CI machines to allow 16k MTU on the loopback? (Note - it's 16336 to make room for the IP headers) You could possibly experiment with different values there. We could add a special set of /* @test */ comments for AIX if adjustments are needed.
25-09-2025
Hello Matthias, > So I guess it is the one with the 16k datagrams, correct (defaultMTU=16336 or is it the chunks value) ? The jtr file of the failure will have the exact detail about which test action failed. Would you be able to share that file? In any case, please create a separate JBS issue with the details so that the jtr can be attached to that.
25-09-2025
this one fails : command: testng -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -Dsimpleget.requests=150 -Dsimpleget.chunks=16384 -Djdk.httpclient.retryOnStreamlimit=5 -Djdk.httpclient.redirects.retrylimit=6 -Djdk.httpclient.quic.defaultMTU=16336 H3SimpleGet reason: User specified action: run testng/othervm/timeout=480 -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -Dsimpleget.requests=150 -Dsimpleget.chunks=16384 -Djdk.httpclient.retryOnStreamlimit=5 -Djdk.httpclient.redirects.retrylimit=6 -Djdk.httpclient.quic.defaultMTU=16336 H3SimpleGet So I guess it is the one with the 16k datagrams, correct (defaultMTU=16336 or is it the chunks value) ?
25-09-2025
[~mbaesken] This test is half-way between a regular test and a stress test. Each config has three `@run` lines. It would be interesting to see which `@run` fails. One of the `@run` assumes that you can use 16k datagrams on the loopbak. This can be system dependent.
25-09-2025
Hi, after this has been pushed, we see those 2 tests failing on AIX , with timeouts. All the other tests that came with this huge change seem to do well , also on AIX. Is there something special with this test so that it causes trouble on some OS ? java/net/httpclient/http3/H3SimpleGet.java#useNioSelector java/net/httpclient/http3/H3SimpleGet.java#with-continuations java.io.IOException: connection idle timed out (30000 milli seconds) at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:1010) at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133) at H3SimpleGet.test(H3SimpleGet.java:227) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1604) at org.testng.TestRunner.privateRun(TestRunner.java:764) at org.testng.TestRunner.run(TestRunner.java:585) at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) at org.testng.SuiteRunner.run(SuiteRunner.java:286) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) at org.testng.TestNG.runSuites(TestNG.java:1069) at org.testng.TestNG.run(TestNG.java:1037) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:107) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:63) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) Caused by: java.io.IOException: connection idle timed out (30000 milli seconds) 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.IdleTimeoutManager.idleTimedOut(IdleTimeoutManager.java:349) at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager$IdleTimeoutEvent.terminateNow(IdleTimeoutManager.java:437) at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager$IdleTimeoutEvent.handle(IdleTimeoutManager.java:411) at java.net.http/jdk.internal.net.http.quic.QuicTimerQueue.processDue(QuicTimerQueue.java:298) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614) ... 1 more =============================================== java/net/httpclient/http3/H3SimpleGet.java#useNioSelector Total tests run: 1, Passes: 0, Failures: 1, Skips: 0 ===============================================
25-09-2025
Changeset: e8db14f5 Branch: master Author: Daniel Fuchs <dfuchs@openjdk.org> Date: 2025-09-22 10:12:12 +0000 URL: https://git.openjdk.org/jdk/commit/e8db14f584fa92db170e056bc68074ccabae82c9
22-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24751 Date: 2025-04-18 13:05:24 +0000
18-04-2025

Blocks :	JDK-8355042 - HTTP/3: reenable tools/sincechecker/modules/java.net.http/JavaNetHttpCheckSince.java before integration
Blocks :	JDK-8291976 - JEP 517: HTTP/3 for the HTTP Client API
CSR :	JDK-8350588 - Implement JEP 517: HTTP/3 for the HTTP Client API
Relates :	JDK-8368739 - [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail
Relates :	JDK-8229533 - HttpClient.Version should provide an enum value for HTTP/3

JDK-8355042 :	HTTP/3: reenable tools/sincechecker/modules/java.net.http/JavaNetHttpCheckSince.java before integration - Resolved
JDK-8365793 :	Consider merging H3UnsupportedSSLParametersTest with H3QuicTLSConnection. - Open
JDK-8365794 :	StreamLimitTest vs H3StreamLimitReachedTest: consider renaming or merging - Open
JDK-8365795 :	Revisit http2/RedirectTest to use HttpServerAdapters and remove Http2RedirectHandler.java - Open
JDK-8365796 :	Consider merging quic/packets/QuicPacketNumbersTest.java and quic/PacketNumbersTest.java - Open
JDK-8365800 :	Consider merging http3/BadCipherSuiteErrorTest with H3QuicTLSConnection - Open
JDK-8365802 :	AsFileDownloadTest should stop using Http2TestServer API - it should use HttpTestServer instead. - Open
JDK-8365872 :	QUIC: Do not derive server's 1-RTT keys until the client's TLS Finished message is processed - Open
JDK-8366184 :	Add tests to verify the SSL AlgorithmConstraints used by the QuicTLSEngine - Open
JDK-8366578 :	Consider removing the field tagSize in various QuicPacketEncoder.OutgoingQuicPacket subclasses - Open