RFR: 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout [v3]

[Daniel Fuchs]

On Thu, 27 Nov 2025 07:08:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
>> 
>> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
>> 
>> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
>> 
>> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
>> 
>> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those reques...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix duration overflow issue with Duration.toMillis()

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 138:

> 136:     // true if this connection has been placed in the HTTP/3 connection pool of the HttpClient.
> 137:     // false otherwise.
> 138:     private volatile boolean presentInConnPool;

In theory a connection that is not in the pool should be marked as `finalStream` ;

src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 917:

> 915:             // in the pool (thus idle), then we instruct QUIC to generate traffic on the
> 916:             // QUIC connection to prevent it from being idle terminated.
> 917:             final boolean generateTraffic = this.presentInConnPool

I wonder if `this.presentInConnPool` can be replaced with `!this.finalStream`

test/jdk/java/net/Foo.java line 1:

> 1: import java.net.InetSocketAddress;

Seems that this file was added by mistake

-------------

PR Review: https://git.openjdk.org/jdk/pull/28522#pullrequestreview-3514375028
PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567867831
PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567882968
PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567892716