-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8317522: Test logic for BODY_CF in AbstractThrowingSubscribers.java is wrong #16041
Conversation
👋 Welcome back dfuchs! A progress list of the required criteria for merging this PR into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
@dfuch This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 8 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit 4c5b66d.
Your commit was automatically rebased without conflicts. |
The
AbstractThrowingSubscribers.java
test class makes the assumption that the HttpClient will cancel a request if the bodyCompletableFuture
returned by aBodySubscriber::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 legitimately 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 is now modified to reflect this. Commenting the line that cancels the subscription in
ThrowingBodySubscriber::getBody
would now make the test fail. The test was previously passing "by chance" because the whole response was contained in a singleDataFrame
(orByteBuffer
for HTTP/1.1).Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16041/head:pull/16041
$ git checkout pull/16041
Update a local copy of the PR:
$ git checkout pull/16041
$ git pull https://git.openjdk.org/jdk.git pull/16041/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 16041
View PR using the GUI difftool:
$ git pr show -t 16041
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16041.diff
Webrev
Link to Webrev Comment