On Thu, 27 Nov 2025 07:08:26 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 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
