On Fri, 28 Nov 2025 11:46:29 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 reques... > > Jaikiran Pai has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains nine additional > commits since the last revision: > > - merge latest from master branch > - don't explicitly generate QUIC traffic for connection marked as finalStream > - Daniel's suggestion - remove Math.addExact() calls > - merge latest from master branch > - remove unwanted file > - fix duration overflow issue with Duration.toMillis() > - fix unintended check > - merge latest from master branch > - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is > configured with a higher idle timeout Thank you Daniel for the review. My test repeat and tier testing completed normally too. I'll go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28522#issuecomment-3590779045
