On Thu, 24 Apr 2025 08:53:42 GMT, Kevin Walls <kev...@openjdk.org> wrote:
> This issue was hard to reproduce or had stopped happening, but was likely a
> failure to capture the main arguments from a monitored process, caused by
> slow startups e.g. -Xcomp. Recent failures seen in Graal testing are most
> likely the same issue and increasing ARGS_ATTEMPTS has been seen to resolve
> it.
>
> While updating the test, fix the very verbose logging: it doesn't need to
> log, every second, how many nanos it has waited.
> This has made logs from timeouts hardly usable as they are truncated and may
> miss critical info. Also, group the "tunable" constants together.
test/jdk/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java line 254:
> 252: String timeoutFactorText =
> System.getProperty("test.timeout.factor", "1.0");
> 253: double timeoutFactor = Double.parseDouble(timeoutFactorText);
> 254: long timeoutNanos = 1000_000_000L*(long)(REMOVE_TIMEOUT *
> timeoutFactor);
I don't understand the need for this already large timeout, and making it
larger (now 2000 seconds instead of 1000). Is it because failures in
hasMainArgs() takes time to timeout? If so, I thought attach failures only took
10 seconds to time out, and we are at most retrying 5 times.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24843#discussion_r2058903444
