On Mon, 17 Oct 2022 19:09:11 GMT, Daniel Fuchs <[email protected]> wrote:

>> When [JDK-8277969](https://bugs.openjdk.org/browse/JDK-8277969) was 
>> implemented, a list of outstanding response subscribers was added to 
>> `HttpClientImpl`. A body subscriber is added to the list after being created 
>> and is removed from the list when it is completed, either successfully or 
>> exceptionally.
>> 
>> It appears that in the case where the subscription is cancelled before the 
>> subscriber is completed, the subscriber might remain registered in the list 
>> forever, or at least until the HttpClient gets garbage collected. This can 
>> be easily reproduced using streaming subscribers, such as 
>> BodySubscriber::ofInputStream. In the case where the input stream is closed 
>> without having read all the bytes, Subscription::cancel will be called. 
>> Whether the subscriber gets unregistered or not at that point becomes racy.
>> 
>> Indeed, the reactive stream specification doesn't guarantee whether 
>> onComplete or onError will be called or not after a subscriber cancels its 
>> subscription. Any cleanup that would have been performed by 
>> onComplete/onError might therefore need to be performed when the 
>> subscription is cancelled too.
>
> Daniel Fuchs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Incorporated review feedback

I have updated the PR. There's a somewhat larger change in how tests can now 
track HttpClients. I noticed that `ReferenceTracker::check(gracedelay)` wasn't 
actually checking that all client selector managers threads had exited (as I 
thought it did) so I changed it to do that, and the SmallTimeout test started 
failing, so I had to fix that test to null out references and actually wait 
until all tasks had been executed.

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

PR: https://git.openjdk.org/jdk/pull/10659

Reply via email to