On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs <[email protected]> wrote:
>> Please find enclosed a patch that solves an intermittent issue detected by
>> the CancelRequestTest.java
>>
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled
>> after the Http2Connection has been created, and the handshake has proceeded,
>> and the response headers to the upgrade have been received, but before the
>> HTTP/2 connection is offered to the HTTP/2 connection pool, the underlying
>> TCP connection might get closed at a time where it won't be noticed
>> immediately, resulting in putting a "dead" HTTP/2 connection in the pool.
>> The next request to the same server will then fail with
>> "ClosedChannelException".
>>
>> The fix is to check the state of the underlying TCP connection before
>> offering the HTTP/2 connection to the pool, and when retrieving it from the
>> pool, and disabling the "connectionAborter" (which is there to abort the
>> connection in case of connect timeout, or cancellation before connect is
>> done) before offering the connection to the pool as well.
>
> Daniel Fuchs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Copyright years
src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line
155:
> 153: boolean offerConnection(Http2Connection c) {
> 154: if (debug.on()) debug.log("offering to the connection pool: %s",
> c);
> 155: if (!c.isOpen() || c.finalStream()) {
Is this check for isOpen() not redundant given the same check added inside the
synchronized block?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7776
