RFR: 8316580: HttpClient with StructuredTaskScope does not close when a task fails [v3]

Daniel Jeliński djelinski at openjdk.org
Tue Sep 26 09:29:17 UTC 2023


On Mon, 25 Sep 2023 15:20:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi, 
>> 
>> Please find below a fix for 8316580: HttpClient with StructuredTaskScope does not close when a task fails.
>> 
>> The problem here is a subtle reference release issue: Interrupting the VirtualThread means that the CompletableFuture returned by sendAsync is eligible for GC after having been cancelled, which in turn means that some of the intermediate operations that would have been completed before that CF was completed get eligible for being GC’ed too. One of these intermediate operations is the action that decrements the ref counting. Since the refcount isn’t decremented properly, the client won’t exit. 
>> 
>> Holding onto the CompletableFuture returned to the caller by HttpClient::sendAsync until that CompletableFuture gets completed from upstream fixes the issue.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Rename test, use TestTaskScope
>  - Make the test independent of any preview API, and use regular threads
>  - Improve the fix to make sure dependent actions are all executed
>  - Merge branch 'master' into HttpGetWithCancelledStructuredScope-8316580
>  - Merge branch 'master' into HttpGetWithCancelledStructuredScope-8316580
>  - 8316580

src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 405:

> 403:             // make sure to fail with CancellationException if cancel(true)
> 404:             // was called.
> 405:             t = cancellationException(t);

What's the reason for this change?

test/jdk/java/net/httpclient/HttpGetInCancelledFuture.java line 97:

> 95:     }
> 96: 
> 97:     static final String HOST = "localhost:62057";

Should we have something listening on that port? Some of our tests used to fail after receiving an unexpected connenction, and 62057 is in the ephemeral range.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15883#discussion_r1336823962
PR Review Comment: https://git.openjdk.org/jdk/pull/15883#discussion_r1336900418


More information about the net-dev mailing list