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 generate the necessary traffic to keep the connection alive (for example if the response processing is taking a long time on the server side, then the server is expected to generate a PING to keep that connection active). A new jtreg test has been introduced to verify that a HTTP/3 connection with a higher idle timeout than the QUIC idle timeout, doesn't cause the connection to be idle terminated by QUIC. ------------- Commit messages: - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout Changes: https://git.openjdk.org/jdk/pull/28522/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371802 Stats: 628 lines in 8 files changed: 529 ins; 50 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/28522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522 PR: https://git.openjdk.org/jdk/pull/28522
