8371559: Intermittent timeouts in test javax/net/ssl/Stapling/HttpsUrlConnClient.java

[ArnoZeller]

This pull request is a clean backport of JDK-8371559.
It is a test only change.

---

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-8371559: Intermittent timeouts in test javax/net/ssl/Stapling/HttpsUrlConnClient.java (Bug - P3)

Reviewers

• Mikhail Yankelevich (@myankelev - Committer)
• Christoph Langer (@RealCLanger - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/29294/head:pull/29294
$ git checkout pull/29294

Update a local copy of the PR:
$ git checkout pull/29294
$ git pull https://git.openjdk.org/jdk.git pull/29294/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 29294

View PR using the GUI difftool:
$ git pr show -t 29294

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/29294.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

[openjdk]

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

8371559: Intermittent timeouts in test javax/net/ssl/Stapling/HttpsUrlConnClient.java

Reviewed-by: myankelevich, clanger

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 15 new commits pushed to the jdk26 branch:

• 7ac780d: Merge
• 4b0189c: 8368032: Enhance Certificate Checking
• ea9f1ed: 8365280: Enhance JOptionPane
• ... and 12 more: https://git.openjdk.org/jdk/compare/f4ddafcd7073994e9b6672df79128c9474b45dcd...jdk26

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@myankelev, @RealCLanger) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[openjdk]

@ArnoZeller The following label will be automatically applied to this pull request:

• security

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.

[mlbridge]

Webrevs

• 00: Full (85d87f06)

[myankelev]

This looks good. But wouldn't it make more sense to just add this fix to 26u?

[ArnoZeller]

This looks good. But wouldn't it make more sense to just add this fix to 26u?

@myankelev: I thought it would be nice to have it in jdk26 from the beginning as it is a clean test only fix. But I can of course go to 26u only and close this - what do you prefer?

[myankelev]

This looks good. But wouldn't it make more sense to just add this fix to 26u?

@myankelev: I thought it would be nice to have it in jdk26 from the beginning as it is a clean test only fix. But I can of course go to 26u only and close this - what do you prefer?

Well, if it blocks your CI - go for it. Otherwise I'd personally hold off until the 26 update as we are in RDP2 now and unless it's critical it should be going to 26u or even just mainline. This is my understanding at least. What do you think?

[ArnoZeller]

Then I would like to go for JDK26, as I do see this failure once or twice a day (probably related to high load on our test machines) in our CI for 26 and haven't had any issue in head since I pushed it there.
@myankelev: Would you be so kind to review it? And do I need a second review because it is after RDP2?

[RealCLanger]

This looks good. But wouldn't it make more sense to just add this fix to 26u?

@myankelev: I thought it would be nice to have it in jdk26 from the beginning as it is a clean test only fix. But I can of course go to 26u only and close this - what do you prefer?

Well, if it blocks your CI - go for it. Otherwise I'd personally hold off until the 26 update as we are in RDP2 now and unless it's critical it should be going to 26u or even just mainline. This is my understanding at least. What do you think?

@myankelev as per the RDP2 rules, test fixes are still accepted, see here: https://openjdk.org/jeps/3. And for our regular testing it would definitely remove noise also in the JDK26 tests.

[jaikiran]

For RDP2, test and doc fixes are noted to require explicit approval https://openjdk.org/jeps/3#rdp-2. The approval process itself is explained here https://openjdk.org/jeps/3#Fix-Request-Process.

[ArnoZeller]

@jaikiran: I am sorry and I might have misunderstood it, but in https://openjdk.org/jeps/3#rdp-2 it says:

Test and documentation bugs and enhancements
Bugs and enhancements of any priority that only affect tests, or test-problem lists, or documentation may be addressed in RDP 1 and RDP 2. You don’t need to request approval for such a change in order to integrate it, but please do make sure that the issue has a noreg-self or noreg-doc label, as appropriate.

And in https://openjdk.org/jeps/3#Fix-Request-Process it states:

Enhancements to tests and documentation during RDP 1 and RDP 2 do not require approval, as long as the relevant issues are identified with a noreg-self or noreg-doc label, as appropriate.

Therefore I thought that I would not need an approval process for this test enhancement with a [noreg-self] label.
But I am new to this RDP2 process and might have gotten it wrong. What should I do now?

[jaikiran]

Hello Arno, the sentence you quoted from https://openjdk.org/jeps/3#Test-and-documentation-bugs-and-enhancements:

Bugs and enhancements of any priority that only affect tests, or test-problem lists, or documentation may be addressed in RDP 1 and RDP 2. You don’t need to request approval for such a change in order to integrate it

does seem to contradict with the "Fix" column for RDP2 row in the table https://openjdk.org/jeps/3#rdp-2, which says:

Current P1–P2, with approval P1–P5 doc/test changes

I'll check internally for clarification on the expected process.

[jaikiran]

Current P1–P2, with approval P1–P5 doc/test changes

I'll check internally for clarification on the expected process.

After checking internally, I realize that I misunderstood that text. It's supposed to read something like "It's OK to fix current P1-P2 issues after getting an approval and OK to fix any P1-P5 doc/test changes". I was also pointed to this section in the OpenJDK guide https://openjdk.org/guide/#push-or-defer-during-ramp-down which has an illustration.

Given this, test-only fixes (like this) are OK in RDP2 and doesn't require an approval.

[ArnoZeller]

@jaikiran: Thanks for the clarification.
@myankelev and @RealCLanger: Thanks for the reviews.

[ArnoZeller]

/integrate

[openjdk]

@ArnoZeller
Your change (at version 85d87f0) is now ready to be sponsored by a Committer.

[RealCLanger]

/sponsor

[openjdk]

Going to push as commit bb9f0f0.
Since your change was applied there have been 15 commits pushed to the jdk26 branch:

• 7ac780d: Merge
• 4b0189c: 8368032: Enhance Certificate Checking
• ea9f1ed: 8365280: Enhance JOptionPane
• ... and 12 more: https://git.openjdk.org/jdk/compare/f4ddafcd7073994e9b6672df79128c9474b45dcd...jdk26

Your commit was automatically rebased without conflicts.

[openjdk]

@RealCLanger @ArnoZeller Pushed as commit bb9f0f0.

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