On Fri, 10 Oct 2025 12:50:42 GMT, Mikhail Yankelevich
<[email protected]> wrote:
>> I believe that increasing the timeout might help, as it seems to be
>> happening due to the machine load. I'm going to make a pr increasing the
>> timeout to 20 from 5 (similar to what it was when timeout factor was 4).
>
> Mikhail Yankelevich has updated the pull request with a new target base due
> to a merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains four additional
> commits since the last revision:
>
> - race condition fix
> - Merge branch 'master' into JDK-8368625
> - race condition fix
> - JDK-8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails
> intermittently in tier7
test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 127:
> 125: // Complete the exchange one second into the future
> 126: final Duration exchangeDuration = Duration.ofSeconds(1);
> 127: final long startTime = System.nanoTime(); // taking custom start
> time just in case
Suggestion:
// taking start time before entering completeExchange to account for
possible
// delays in reaching server.stop().
final long startTime = System.nanoTime();
test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 164:
> 162: // Complete the exchange 10 second into the future.
> 163: // Runs in parallel, so won't block the server stop
> 164: final Duration exchangeDuration =
> Duration.ofSeconds(Utils.adjustTimeout(10));
Looks good, but if this test fail we could envisage bumping that delay though.
A better implementation could be to complete the exchange *after* exiting from
server.stop() - without using any virtual thread, and just verifying that the
server.stop() waited at least for 1s.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2421333349
PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2421380885
