On Tue, 7 Oct 2025 10:11:22 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).
The extending of the stop duration may not have the desired effect of
eliminating what appears to be a race condition in the test
One of the recorded failures is for the temporal condition
// The shutdown should take at least as long as the exchange duration
if (elapsed < exchangeDuration.toNanos()) {
fail("HttpServer.stop terminated before exchange completed");
}
This is a somewhat dubious constraint and can’t always be met
The test assumes that the participating threads are all actively executing
simultaneously, which may not be true
They may be scheduled to run rather than actually running.
Restating the objective of the test
Objective: to ensure that the stop request is not processed while there are
extant exchanges
Potential race scenario:
Server started creates exchange which waits for a signal to complete
Exchange completion thread starts waits for 1 seconds before it can signal
exchange to compete — the complete signal will be thus invoked sometime after 1
second depending on OS thread scheduling
Main thread continues and invokes a stop which has a max wait time of 5 seconds
for extant exchanges to complete — so max completion time of stop is 5 seconds
++ i.e. could be slightly longer than 5 seconds again subject to OS scheduling
Temporal condition imposed by test
// The shutdown should take at least as long as the exchange duration
if (elapsed < exchangeDuration.toNanos()) {
fail("HttpServer.stop terminated before exchange completed");
}
// The delay should not have expired
if (elapsed >= delayDuration.toNanos()) {
fail("HttpServer.stop terminated after delay expired");
}
1. States elapsed time of stop should be less than the duration of the exchange
exchangeDuration. BUT exchangeDuration is not the
duration of the exchange completion. Rather, it is the time delay before the
exchange thread is signalled to complete.
The actual completion of the exchange may be sometime later, again depending on
OS thread scheduling.
Second condition is that the elapsed time of the stop should be less than or
equal to the stop delay. BUT if the full timeout for the
stop expires as per
server.stop will wait a max of N (5) seconds before terminating as per
try {
// waiting for the duration of the delay, unless released before
finishedLatch.await(delay, TimeUnit.SECONDS);
} catch (InterruptedException e) {
logger.log(Level.TRACE, "Error in awaiting the delay");
} finally {
Then this infers that the extant exchanges have taken longer than the expected
or allowed time. This in turn infers that
the exchange is still executing or waiting to execute at the time of the stop
request.
All in all the temporal conditions are not exact and they are subject to
variability depending on the scheduling of threads by the OS.
BUT extending of the delayDuration doesn’t necessarily impact the first
condition, which has failed, because the elapsed time may be less than the
exchange duration due to OS scheduling
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27670#issuecomment-3377522093
