-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8347597: HttpClient: improve exception reporting when closing connection #23080
Conversation
👋 Welcome back dfuchs! A progress list of the required criteria for merging this PR into |
@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 49 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
@@ -331,7 +331,7 @@ public <U> CompletableFuture<U> readBody(HttpResponse.BodySubscriber<U> p, | |||
); | |||
if (cf.isCompletedExceptionally()) { | |||
// if an error occurs during subscription | |||
connection.close(); | |||
connection.close(cf.exceptionNow()); |
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.
Future.exceptionNow()
(among other things) states that it will throw a IllegalStateException
if the Future was cancelled. We do have a check for cf.isCompletedExceptionally()
before invoking this method. However, the CompletableFuture.isCompletedExceptionally()
states that it returns true
even in the case of cancellation:
Returns {@code true} if this CompletableFuture completed exceptionally, in any way. Possible causes include cancellation ...
So I suspect this call to exceptionNow()
might need a rethink or some additional checks?
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.
Good catch. I suspect the case where the CF is cancelled should not occur, but I have added a Utils.exceptionNow method to take care of this case just in case.
testThrowable = e.getCause(); | ||
} | ||
assertNotNull(exception, "Request should have completed exceptionally but exception is null"); |
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.
Unlike the assertNotNull
on the next line, I think it might be better to replace this new assertNotNull
with a fail(...)
inside the try block immediately after the performRequest()
call.
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.
I see what you mean. I reworked that part.
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.
Thank you for the update. This looks good to me.
/integrate |
Going to push as commit 7df21a8.
Your commit was automatically rebased without conflicts. |
There are a few places in the HttpClient code base where we close the connection when some error/exception happens. This can some time trigger a race condition where closing the connection in turns causes a "connection closed locally" exception to get reported instead of the original exception. This typically happens if another thread is attempting to read from / write to the connection concurrently when the original exception that caused the connection to get closed occurred.
The fix makes sure that we store the first exception in the underlying connection before closing it, and that this is the exception that gets subsequently reported.
Some minor drive by test fixes. No new regression test.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23080/head:pull/23080
$ git checkout pull/23080
Update a local copy of the PR:
$ git checkout pull/23080
$ git pull https://git.openjdk.org/jdk.git pull/23080/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23080
View PR using the GUI difftool:
$ git pr show -t 23080
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23080.diff
Using Webrev
Link to Webrev Comment