On Thu, 27 Nov 2025 05:10:48 GMT, Jaikiran Pai <[email protected]> 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 request/responses would ... This pull request has now been integrated. Changeset: 92e1357d Author: Jaikiran Pai <[email protected]> URL: https://git.openjdk.org/jdk/commit/92e1357dfd2d874ef1a62ddd69c86a7bb189c6a2 Stats: 627 lines in 8 files changed: 528 ins; 50 del; 49 mod 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/28522
