On Thu, 6 Nov 2025 16:22:41 GMT, Daniel Fuchs <[email protected]> wrote:
> Nothing looks wrong with the test or the code. The failure happens rarely - > probably when the machine is under load: this test tries to saturate the > socket buffers and is resource consuming. > > The proposed fix is just to double the jtreg timeout for this test from 120 > to 240. It is fine to increase the jtreg test timeout. BUT with the TIMEOUT FACTOR reverted to 4 and hence an overall jtreg timeout 8 minutes, the most likely outcome of increasing the test's explicit timeout to 240 is, when this "moribund" condition arises, for the test to timeout after 16 minutes. The process capture suggests that the writer and reader in the readSlowly and writeSlowly have got stuck It's a complex enough test with the HttpClient also stuck in a "poll" waiting on network events I haven't study the test in depth, but it smells like a race condition/conditions ------------- PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3504071234
