8338569: HTTP/1.1 CleanupTrigger may be triggerred after the next exchange started#20623
8338569: HTTP/1.1 CleanupTrigger may be triggerred after the next exchange started#20623dfuch wants to merge 5 commits intoopenjdk:masterfrom
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 2 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 |
Webrevs
|
|
Note: the changes to ShutdownNow.java are coincidental. I observed this test failing once in my many tests, and decided to make the exception it throws more explicit. FWIW - I had also observed this test failing before the change, it's intermittent and rare. I took the opportunity to raise the timeout from 2000 to 2500. |
src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
Outdated
Show resolved
Hide resolved
jaikiran
left a comment
There was a problem hiding this comment.
This looks OK to me. Some of the files will need a copyright year update before integrating.
src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
Outdated
Show resolved
Hide resolved
|
Copyright years have been updated and the stray printStackTrace() has been removed. |
|
Thanks Jaikiran. I will integrate tomorrow. |
|
/integrate |
|
Going to push as commit 723588a.
Your commit was automatically rebased without conflicts. |
The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool. This should not happen.
The issue is caused by deferred registration of read subscribers with the SocketTube. The subscribers are registered within the SelectorManager thread to ensure proper interaction with the read method.
Sometimes pending subscribers are pushed faster than they are actually subscribed, which may cause the wrong subscriber to be subscribed at the wrong time.
This is a redo of JDK-8336655 which was a failed fix.
The main difference is that the new fix uses a ConcurrentLinkedQueue to make sure all subscribers get subscribed and dropped in the right sequence. Marking previous subscription as stopped ensures that data can only be routed to the last subscriber in the queue.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20623/head:pull/20623$ git checkout pull/20623Update a local copy of the PR:
$ git checkout pull/20623$ git pull https://git.openjdk.org/jdk.git pull/20623/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 20623View PR using the GUI difftool:
$ git pr show -t 20623Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20623.diff
Webrev
Link to Webrev Comment