8301243: java/net/httpclient/http2/IdleConnectionTimeoutTest.java intermittent failure #12457
Conversation
…ermittent failure
|
👋 Welcome back ccleary! A progress list of the required criteria for merging this PR into |
Webrevs
|
| if (!acceptedFirstConnection) { | ||
| firstConnectionHash = exch.getTestConnection().hashCode(); | ||
| acceptedFirstConnection = true; | ||
| exch.sendResponseHeaders(200, 0); | ||
| } else { | ||
| int secondConnectionHash = exch.getTestConnection().hashCode(); | ||
| int cmp = Integer.compare(firstConnectionHash, secondConnectionHash); | ||
|
|
||
| if (cmp < 0 | cmp > 0) { |
There was a problem hiding this comment.
In other words, if (cmp != 0) ? ;-)
It may be simpler and less error prone to save the connection (as an Object) in the handler.
volatile Object previousConnection = null;
Then the condition become:
if (previousConnection == null) {
previousConnection = exch.getTestConnection();
exch.sendResponseHeaders(200, 0);
} else {
var secondConnection = exch.getTestConnection();
if (previousConnection != secondConnection) {
....
There was a problem hiding this comment.
I could be wrong but I think I might have tried that before. What you're calling previousConnection in the sample code you've given gets set to null in the time between the first and second requests during the tests where a timeout fires. Which does serve to test that the connections are different to be fair but maybe for some reason previousConnection could be null that is unrelated to it being closed by the test server. For example createConnection() might close early due to a Reset Stream or Protocol Error.
I know that's very edge case but its the reason I compared using the hash code. I'm open to changing it though of course! Might be less error prone as you say.
Also, very fair on the if (cmp != 0) suggestion 😅 I'll definitely shorten it to that if I stick with the comparison as it is right now.
There was a problem hiding this comment.
I don't see how using the hash wouldn't cause the exact same issue. Also you really need volatile here, since two different requests are going to be handled by two different threads.
|
Changes were simplified, original means of obtaining the hash code of each connection was abandoned in favour of just comparing the object references as @dfuch suggested. |
|
@c-cleary 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 59 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 |
|
As this was a minor change and testing seems to be consistent, I'll proceed with integration |
|
/integrate |
|
Going to push as commit 92474f1.
Your commit was automatically rebased without conflicts. |
openjdk
bot
removed
ready
Description
Intermittent failures of this test are observed on frequent
HttpClienttest runs. The test checks that the same connection is not used twice for two seperate requests if an Idle Connection Timeout occurs by verifying that the client-side port does not use the same port. It also verifies that when an Idle Connection Timeout does not occur, the same connection is used by verifying that the port used in both requests is the same.The issue here is that there is no guarantee that the ports used will not be the same for when an Idle Connection Timeout occurs and so the test will/does fail intermittently.
Summary of Changes & Justification
Instead of comparing the post numbers of the connections used for each request in all test cases, the connections themselves are now compared with calls to
hashCode()like so. The connection instances themselves are accessed by using a customisedExchangeSupplierfor theHttp2TestServer.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/12457/head:pull/12457$ git checkout pull/12457Update a local copy of the PR:
$ git checkout pull/12457$ git pull https://git.openjdk.org/jdk pull/12457/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 12457View PR using the GUI difftool:
$ git pr show -t 12457Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12457.diff