> 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 ...
Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: fix duration overflow issue with Duration.toMillis() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28522/files - new: https://git.openjdk.org/jdk/pull/28522/files/b5208f65..b3b73048 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=01-02 Stats: 30 lines in 2 files changed: 29 ins; 0 del; 1 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
