RFR: 8335181: Incorrect handling of HTTP/2 GOAWAY frames in HttpClient [v5]

[Daniel Fuchs]

On Mon, 12 Aug 2024 07:12:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes the issue noted in https://bugs.openjdk.org/browse/JDK-8335181?
>> 
>> As noted in that issue, the current implementation in the `java.net.http.HttpClient` doesn't correctly handle an incoming GOAWAY frame. The HTTP3 RFC https://www.rfc-editor.org/rfc/rfc9113#name-goaway notes the specifics on what the expectations are when an endpoint receives a GOAWAY frame from the peer.
>> 
>> Before the changes proposed in this PR, the HttpClient implementation would (incorrectly) shutdown the connection and abort requests when a GOAWAY frame was received. The changes in this PR fixes that by retrying relevant unprocessed requests (if any) and not initiating any new streams on the connection.
>> 
>> A new test has been introduced to exercise this detail. The test continues to pass along with other existing tests. tier testing as well as a repeated testing (with test-repeat 50) is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify request approver test construct - no need to expect request path

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 653:

> 651:                     if (debug.on()) {
> 652:                         debug.log("request unprocessed by peer (REFUSED_STREAM) " + this.request);
> 653:                     }

Hmm.... Should we just call:


    closeAsUnprocessed():
    return;


here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20442#discussion_r1713902449