-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b19
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8323456 | 21.0.3-oracle | Ramesh Gangadhar | P4 | Resolved | Fixed | b02 |
JDK-8324061 | 21.0.3 | Goetz Lindenmaier | P4 | Resolved | Fixed | b01 |
The AbstractThrowingSubscribers.java test class makes the assumption that the HttpClient will cancel a request if the body CompletableFuture returned by a BodySubscriber::getBody is completed exceptionally. This assumption is wrong. Indeed, it should be the responsibility of the custom subscriber to cancel its subscription, or not, in such a case, as whether to cancel or not depends on the semantic the subscriber assigns to such a body.
The issue can be observed by modifying the test to send a longer response split in several chunks: with such a configuration, and using streaming body subscribers, such as `ofInputStream`, the test will fail waiting for the HttpClient to be garbaged collected, as the response data will not get pulled and the underlying exchange will never terminate. Though changing the HttpClient code to forcefully cancel the subscription (or the exchange) in such a case would "work", it does not seem desirable: it would introduce a change of behavior that might cause existing applications to fail, and there may be cases where a custom subscriber may want to complete its body CF exceptionally while still continuing to parse the body bytes. Whether to choose to cancel the subscription or not should solely depend on the logic of the custom subscriber.
The test logic should be modified to reflect this.
The issue can be observed by modifying the test to send a longer response split in several chunks: with such a configuration, and using streaming body subscribers, such as `ofInputStream`, the test will fail waiting for the HttpClient to be garbaged collected, as the response data will not get pulled and the underlying exchange will never terminate. Though changing the HttpClient code to forcefully cancel the subscription (or the exchange) in such a case would "work", it does not seem desirable: it would introduce a change of behavior that might cause existing applications to fail, and there may be cases where a custom subscriber may want to complete its body CF exceptionally while still continuing to parse the body bytes. Whether to choose to cancel the subscription or not should solely depend on the logic of the custom subscriber.
The test logic should be modified to reflect this.
- backported by
-
JDK-8323456 Test logic for BODY_CF in AbstractThrowingSubscribers.java is wrong
- Resolved
-
JDK-8324061 Test logic for BODY_CF in AbstractThrowingSubscribers.java is wrong
- Resolved
- links to
-
Commit openjdk/jdk21u-dev/0668efa6
-
Commit openjdk/jdk/4c5b66dc
-
Review openjdk/jdk21u-dev/171
-
Review openjdk/jdk/16041
(1 links to)