While at it, in your application could you also check what the server
sends for the "max_idle_timeout" QUIC transport parameter
https://www.rfc-editor.org/rfc/rfc9000#section-18.2-4.4.1? If that's not
easy to locate, then you could enable (very verbose) logging of the
JDK's HttpClient by setting the -Djdk.internal.httpclient.debug=true
system property and rerunning the application. It will generate lots of
logs, but you could search for "max_idle_timeout" or even "Received peer
Quic transport params" text in that log.
-Jaikiran
On 10/11/25 3:29 pm, Jaikiran Pai wrote:
Hello Josiah,
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.QuicConnectionImpl
pushDatagram
INFO: QUIC: QuicClientConnection(1) OUT: ONERTT(pn:4, size=75,
phase:-1, spin:-1, frames:[StreamFrame(stream=0, offset=0, length=2,
fin=false), StreamFrame(stream=0, offset=2, length=2, fin=false),
StreamFrame(stream=0, offset=4, length=34, fin=true)])
...
INFO: QUIC: QuicClientConnection(1): APPLICATION no deadline, task
unscheduled
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.quic.IdleTimeoutManager
idleTimedOut
The long running request, is it generating any response during those
30 seconds from the server to the client or is it handling the request
on the server side without generating any traffic during that period.
This does look like an issue we need to look into, so having that
detail would help.
-Jaikiran
On 08/11/25 9:53 pm, Josiah Noel wrote:
Long time no see,
I was trying a long running request with the new client and it seems
that after 30 seconds it cuts the request, regardless of whether I
specify a longer request timeout. Is there a different mechanism for
configuration?
--
Cheers, Josiah.
