On Thu, 9 Oct 2025 10:00:17 GMT, Stefan Karlsson <[email protected]> wrote:
> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the > default TIMEOUT_FACTOR from 1 to 4 to make it easier to understand how our > timeouts worked. Together with that small change, we also bumped a number of > tests that relied on the previous extended timeout. The anticipation was that > there would be some fallout from that change and that we for a short time > after it had been integrated would have to tweak some tests that > intermittently needed a larger timeout. > > It turns out that the way we run tests concurrently causes the tests to > sometimes run in a resource-constrained manner. This has the effect that even > simple tests that usually don't take a long time to execute run the risk of > hitting the default 120s timeout limit. This invalidates the earlier plan to > fix the additional, few tests that now times out, because it's probably not > the tests themselves that are the problem, but rather how we run the tests. > > Hunting down the reasons for the new set of timeouts we are seeing is good > and figuring out how to fix our testing to not over-strain our testing > machines is also something that we want to do. The problem is that there's > enough of these timeouts that it affects more than just a limited set of JDK > devs. > > The proposal is that we, for now, revert back to the default timeout factor > of 4 to relive the pressure to investigate and fix these intermittent > timeouts. And revert back to 1 once enough investigation and tweaks have been > made to the test infrastructure. > > I will run this through Oracle's tier1-tier8 testing. Marked as reviewed by prr (Reviewer). I don't have much visibility into how this affected other areas but I was surprised that a test that for me runs in a couple of seconds was apparently timing out on some systems (not the Oracle CI but some external one). In the PR to resolve this I suggested (https://github.com/openjdk/jdk/pull/27397#discussion_r2383687871) that we may be using too high a concurrency as chosen by the build as tests could be more sensitive to this. But I also see that if you have a system with N CPUs it is a waste to only use (eg) N/2 because "some" test might time out. A compromise may be needed. ------------- PR Review: https://git.openjdk.org/jdk/pull/27721#pullrequestreview-3321344090 PR Comment: https://git.openjdk.org/jdk/pull/27721#issuecomment-3388293960
