8304174: Remove delays from httpserver tests

[djelinski]

This change improves the running time of many httpserver tests; it removes the one second delay introduced by delay() calls, and performs immediate httpserver stop by calling stop(0).

For example, com/sun/net/httpserver/Test1.java usually takes 20-30 seconds without this change; with this change it completes in 5-8 seconds.

Tiers 1-3 still green.

---

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-8304174: Remove delays from httpserver tests

Reviewers

• Jaikiran Pai (@jaikiran - Reviewer)
• Daniel Fuchs (@dfuch - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13028

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

Using diff file

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

[bridgekeeper]

👋 Welcome back djelinski! 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]

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

• net

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 (810cf06b)

[jaikiran]

Hello Daniel, the changes look good to me. Like you note, I don't see any of these tests relying on the delay of server stop() for their tests. It's a bit surprising that a lot of these tests were using those delays, but I guess that's because one test influencing the code in another test.

[jaikiran]

For example, com/sun/net/httpserver/Test1.java usually takes 20-30 seconds without this change; with this change it completes in 5-8 seconds.

That's a good improvement.

[openjdk]

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

8304174: Remove delays from httpserver tests

Reviewed-by: jpai, dfuchs

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 56 new commits pushed to the master branch:

• e339e18: 7016187: javac -h could generate conflict .h for inner class and class name with '_'
• 033c0b1: 8304437: ProblemList com/sun/jdi/ThreadMemoryLeadTest.java with ZGC
• 7503ecc: 8304138: [JVMCI] Test FailedSpeculation existence before appending.
• f8482c2: 8297638: Memory leak in case of many started-dead threads
• c56f011: 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53"
• 254288a: 8014021: TreeMaker.Params behaves inconsistently when the owning method has the same number of parameters as the number of parameter types requested
• 8f5bb53: 8015831: Add lint check for calling overridable methods from a constructor
• b085ab9: 8180387: com.sun.source.util.JavacTask should have a protected constructor.
• bfb812a: 8292818: replace 96-bit representation for field metadata with variable-sized streams
• 932be35: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders
• ... and 46 more: https://git.openjdk.org/jdk/compare/830fd413461709a494bcb81952e5c32088676ee3...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.

[msheppar]

From my observations, typically these delays have been used to provide a level of synchronicity between the main thread and various background processing threads. Thus, allowing background processing to conclude prior to the actual shutdown in the server. For example, if you analyse the HttpServerTest, there exists some potential for race conditions to occur. An influencing factor, in all this, is the load on the test system and the number of threads executing. With these changes there may be some intermittent failures -- so one to watch !!

[dfuch]

A better solution might be to revisit HttpServer::stop. That would involve implementing proper exchange ref counting, with a guarantee that the ref count can't be transiently observed as 0 after a new request has been accepted and before it is actually handled - which may not be easy. I suspect the current strategy of waiting a couple of seconds might have hidden a number of potential shutdown races. Though if you can verify that your proposed change doesn't actually introduce any intermittent failures (as Mark is worried about) I would have no objection.

[djelinski]

Thanks for your comments!
In most of the tests, all requests are done when we stop the server.
I checked the HttpServerTest; moved serverStopped.await(); before is.readAllBytes(); to make sure the wrong side wins the race. The test still passed.
If the tests start failing, we will fix the races using the proper synchronization objects like CountDownLatch. For now, after 50 reps of com/sun/net/httpserver tests I have zero failures.

I plan to revisit HttpServer::stop in JDK-8304065. However, even when implemented correctly, stop(1) will be slightly slower than stop(0).

[djelinski]

50 repeats of tests using SimpleHttpServer also passed. Removing the delays appears to have no effect on test stability.

[djelinski]

/integrate

[openjdk]

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

• c09f83e: 8304293: RISC-V: JDK-8276799 missed atomic intrinsic support for C1
• e339e18: 7016187: javac -h could generate conflict .h for inner class and class name with '_'
• 033c0b1: 8304437: ProblemList com/sun/jdi/ThreadMemoryLeadTest.java with ZGC
• 7503ecc: 8304138: [JVMCI] Test FailedSpeculation existence before appending.
• f8482c2: 8297638: Memory leak in case of many started-dead threads
• c56f011: 8298995: tools/jpackage/share/AddLauncherTest.java#id1 failed "AddLauncherTest.test; checks=53"
• 254288a: 8014021: TreeMaker.Params behaves inconsistently when the owning method has the same number of parameters as the number of parameter types requested
• 8f5bb53: 8015831: Add lint check for calling overridable methods from a constructor
• b085ab9: 8180387: com.sun.source.util.JavacTask should have a protected constructor.
• bfb812a: 8292818: replace 96-bit representation for field metadata with variable-sized streams
• ... and 47 more: https://git.openjdk.org/jdk/compare/830fd413461709a494bcb81952e5c32088676ee3...master

Your commit was automatically rebased without conflicts.

[openjdk]

@djelinski Pushed as commit 4505670.

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