Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

dfuch
Copy link
Member

@dfuch dfuch commented Jan 13, 2025

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

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8347597: HttpClient: improve exception reporting when closing connection (Bug - P4)

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

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 13, 2025

👋 Welcome back dfuchs! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Jan 13, 2025

@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:

8347597: HttpClient: improve exception reporting when closing connection

Reviewed-by: jpai

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 master branch:

  • 35be4a4: 8347173: java/net/DatagramSocket/InterruptibleDatagramSocket.java fails with virtual thread factory
  • 36b7abd: 8225763: Inflater and Deflater should implement AutoCloseable
  • d6d45c6: 8303884: jlink --add-options plugin does not allow GNU style options to be provided
  • 0ee6ba9: 8347596: Update HSS/LMS public key encoding
  • ec2aaaa: 8326236: assert(ce != nullptr) failed in Continuation::continuation_bottom_sender
  • 02d2493: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java
  • 10d08db: 8346142: [perf] scalability issue for the specjvm2008::xml.validation workload
  • 9b1bed0: 8290043: serviceability/attach/ConcAttachTest.java failed "guarantee(!CheckJNICalls) failed: Attached JNI thread exited without being detached"
  • 2de71d0: 8347129: cpuset cgroups controller is required for no good reason
  • 4c30933: 8346971: [ubsan] psCardTable.cpp:131:24: runtime error: large index is out of bounds
  • ... and 39 more: https://git.openjdk.org/jdk/compare/06126361db1edb1d4c181a82952c1ac133a839f9...master

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the rfr Pull request is ready for review label Jan 13, 2025
@openjdk
Copy link

openjdk bot commented Jan 13, 2025

@dfuch The following labels will be automatically applied to this pull request:

  • net
  • security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added security security-dev@openjdk.org net net-dev@openjdk.org labels Jan 13, 2025
@mlbridge
Copy link

mlbridge bot commented Jan 13, 2025

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());
Copy link
Member

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?

Copy link
Member Author

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");
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@jaikiran jaikiran left a 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.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jan 15, 2025
@dfuch
Copy link
Member Author

dfuch commented Jan 15, 2025

/integrate

@openjdk
Copy link

openjdk bot commented Jan 15, 2025

Going to push as commit 7df21a8.
Since your change was applied there have been 61 commits pushed to the master branch:

  • b0e2be6: 8347729: Replace SIZE_FORMAT in parallel and serial gc
  • d4e5ec2: 8346610: Make all imports consistent in the FFM API
  • c36200b: 8347721: Replace SIZE_FORMAT in compiler directories
  • af3f5d8: 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running
  • 91197b3: 8347531: The signal tests are failing after JDK-8345782 due to an unrelated warning
  • 4f3dc9d: 8347352: RISC-V: Cleanup bitwise AND assembler routines
  • afc4529: 8346834: Tests failing with -XX:+UseNUMA due to "NUMA support disabled" warning
  • a3be97e: 8347761: Test tools/jimage/JImageExtractTest.java fails after JDK-8303884
  • 28e01e6: 8347762: ClassFile attribute specification refers to non-SE modules
  • be1cdd9: 8344140: Refactor the discovery of AOT cache artifacts
  • ... and 51 more: https://git.openjdk.org/jdk/compare/06126361db1edb1d4c181a82952c1ac133a839f9...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jan 15, 2025
@openjdk openjdk bot closed this Jan 15, 2025
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 15, 2025
@openjdk
Copy link

openjdk bot commented Jan 15, 2025

@dfuch Pushed as commit 7df21a8.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated net net-dev@openjdk.org security security-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.

2 participants