-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
JDK-8311792: java/net/httpclient/ResponsePublisher.java fails intermittently with AssertionError: Found some outstanding operations #15307
Conversation
👋 Welcome back dclarke! A progress list of the required criteria for merging this PR into |
@DarraghClarke The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
System.gc(); | ||
System.out.println(now() + "waiting for client to shutdown: " + tracker.getName()); | ||
System.err.println(now() + "waiting for client to shutdown: " + tracker.getName()); | ||
var error = TRACKER.check(tracker, 10000); |
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.
Hello Darragh, 10 seconds looks a bit too large, even if it's the max time to wait. Before this change the graceDelayms was 500 milli seconds. So this appears to be a big jump. Perhaps we should start with something like 2 or 5 seconds (an arbitrary number, I admit)?
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.
It shouldn't take 10 seconds for the client to shutdown, so it shouldn't matter that we use a large timeout. I we used HttpClient::close() we would wait forever (that is - we would wait for as long as it takes).
I believe 500ms to wait for the GC to kick in was a bit optimistic for cases where the machine is overloaded by other tasks. Waiting for a client to be gc'ed or closed until we create the next one should help, as it will ensure there are no lingering resources waiting to be released.
The advantage of using close() is that it is much cleaner and simpler. The disadvantage is that if it fails in timeout there, you have no clue about what prevented close() to finish. In opposition the tracker will provide diagnosis if the client fails to close in the imparted delay.
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.
The advantage of using close() is that it is much cleaner and simpler. The disadvantage is that if it fails in timeout there, you have no clue about what prevented close() to finish. In opposition the tracker will provide diagnosis if the client fails to close in the imparted delay.
That sounds reasonable to me. The changes look fine in this PR.
// Wait for the client to be garbage collected. | ||
// we use the ReferenceTracker API rather than HttpClient::close here, | ||
// because these tests inject faults by throwing inside callbacks, which | ||
// is more likely to get HttpClient::close wedged until jtreg times out. |
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.
Is this comment and the decision to not use HttpClient.close()
in this test relevant to this test case? In AbstractThrowingPublishers
, which is where this comment initially resided like you note in the PR description, I think it was relevant. I haven't thoroughly looked at the tests in this ResponsePublisher
test, so unsure if we can't/shouldn't use HttpClient.close()
in these test methods.
System.gc(); | ||
System.out.println(now() + "waiting for client to shutdown: " + tracker.getName()); | ||
System.err.println(now() + "waiting for client to shutdown: " + tracker.getName()); | ||
var error = TRACKER.check(tracker, 10000); |
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.
It shouldn't take 10 seconds for the client to shutdown, so it shouldn't matter that we use a large timeout. I we used HttpClient::close() we would wait forever (that is - we would wait for as long as it takes).
I believe 500ms to wait for the GC to kick in was a bit optimistic for cases where the machine is overloaded by other tasks. Waiting for a client to be gc'ed or closed until we create the next one should help, as it will ensure there are no lingering resources waiting to be released.
The advantage of using close() is that it is much cleaner and simpler. The disadvantage is that if it fails in timeout there, you have no clue about what prevented close() to finish. In opposition the tracker will provide diagnosis if the client fails to close in the imparted delay.
Co-authored-by: Daniel Fuchs <67001856+dfuch@users.noreply.github.com>
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. Please make sure the changed test passes reliably in the CI before integrating.
@DarraghClarke 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 174 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 |
I reran the tests and everything is passing |
/integrate |
Going to push as commit 1664e79.
Your commit was automatically rebased without conflicts. |
@DarraghClarke Pushed as commit 1664e79. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Currently
ResponsePublisher
occasionally fails due to unreleased resources.Updated test based on AbstractThrowingPushPromises to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
I ran tiers 1-3 and everything is passing
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15307/head:pull/15307
$ git checkout pull/15307
Update a local copy of the PR:
$ git checkout pull/15307
$ git pull https://git.openjdk.org/jdk.git pull/15307/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 15307
View PR using the GUI difftool:
$ git pr show -t 15307
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15307.diff
Webrev
Link to Webrev Comment