-
Bug
-
Resolution: Fixed
-
P3
-
19
-
b21
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8357890 | 17.0.17-oracle | Weibing Xiao | P3 | Resolved | Fixed | master |
When 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 is then 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 too when the subscription is cancelled.
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 is then 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 too when the subscription is cancelled.
- backported by
-
JDK-8357890 Cancelling a request must eventually cause its response body subscriber to be unregistered
-
- Resolved
-
- relates to
-
JDK-8277969 HttpClient SelectorManager shuts down when custom Executor rejects a task
-
- Resolved
-
-
JDK-8296889 Race condition when cancelling a request
-
- Closed
-
-
JDK-8298340 java/net/httpclient/CancelRequestTest.java fails with AssertionError: Found some subscribers for testPostInterrupt
-
- Closed
-
(1 links to)