JDK-8368098 : (aio) java/nio/channels/Channels/AsyncCloseStreams.java fails in junit timeout
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2025-09-19
  • Updated: 2025-10-21
  • Resolved: 2025-10-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 b20Fixed
Related Reports
Causes :  
JDK-8260555 - Change the default TIMEOUT_FACTOR from 4 to 1
Relates :  
JDK-8368290 - java/nio/channels/AsyncCloseAndInterrupt.java fails with timeout
Relates :  
JDK-8368001 - java/text/Format/NumberFormat/NumberRoundTrip.java timed out
Description
The timeout for the test should probably be increased. 
It looks like the test passed, but still took too long.

----------System.err:(16/635)----------
STARTED    AsyncCloseStreams::available 'available()'
AsynchronousCloseException caught
SUCCESSFUL AsyncCloseStreams::available 'available()' [622ms]
STARTED    AsyncCloseStreams::read 'read()'
AsynchronousCloseException caught
SUCCESSFUL AsyncCloseStreams::read 'read()' [559ms]
STARTED    AsyncCloseStreams::write 'write()'
AsynchronousCloseException caught
SUCCESSFUL AsyncCloseStreams::write 'write()' [121875ms]

[ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0]
[ JUnit Tests: found 3, started 3, succeeded 3, failed 0, aborted 0, skipped 0]


JavaTest Message: Test complete.

result: Error. "junit" action timed out with a timeout of 120 seconds on agent 13


test result: Error. "junit" action timed out with a timeout of 120 seconds on agent 13
Comments
Changeset: 8b1cf8ee Branch: master Author: Brian Burkhalter <bpb@openjdk.org> Date: 2025-10-13 16:03:43 +0000 URL: https://git.openjdk.org/jdk/commit/8b1cf8eefe4e3439dba983bced06d55a6ca7da4e
13-10-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27750 Date: 2025-10-10 16:31:38 +0000
10-10-2025
JDK-8369491 proposes revert TIMEOUT_FACTOR back to 4 so the timeout reported here won't reproduce. That said, it would be useful to get a sense of the execution time. If it is close to the 120s on slow+busy test machines then it would be good to add an explicit timeout.
10-10-2025
AsyncCloseStreams::read already reads 100_000 bytes at a time so increasing the buffer size in AsyncCloseStreams::write would make them equivalent. That AsyncCloseStreams::write is not already like this was probably an oversight.
09-10-2025
> the following shows that the test scenarios have passed, so it not a question that the AsynchronousCloseException was not thrown ... the test requires > 2minutes to tidy up AsyncCloseStreams::write will loop indefinitely until it gets AsynchronousCloseException. It calls write with a single byte. The suggestion is to use a large buffer and see if that improves the chances of AsynchronousCloseException being throw, thus reduced the test execution time. If that doesn't help then we'll need to add an explicit timeout to this test.
03-10-2025
One thing to try changing `out.write(27);` to write a 100K byte array so that the write has more work today. That should improve the chances of AsynchronousCloseException being thrown. Putting a limit of the number of attempts would be feasible too, but it means the original issue isn't reliably tested.
03-10-2025
the following shows that the test scenarios have passed, so it not a question that the AsynchronousCloseException was not thrown ... the test requires > 2minutes to tidy up STARTED AsyncCloseStreams::available 'available()' AsynchronousCloseException caught SUCCESSFUL AsyncCloseStreams::available 'available()' [31ms] STARTED AsyncCloseStreams::read 'read()' AsynchronousCloseException caught SUCCESSFUL AsyncCloseStreams::read 'read()' [31ms] STARTED AsyncCloseStreams::write 'write()' AsynchronousCloseException caught SUCCESSFUL AsyncCloseStreams::write 'write()' [122056ms] <<--- Test completed successfully [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0] [ JUnit Tests: found 3, started 3, succeeded 3, failed 0, aborted 0, skipped 0] JavaTest Message: Test complete. result: Error. "junit" action timed out with a timeout of 120 seconds on agent 12 test result: Error. "junit" action timed out with a timeout of 120 seconds on agent 12 and the issue is the now reduced 2 minute timeout which expires before the test tidy up is complete. This is similar to the failure scenario recorded in https://bugs.openjdk.org/browse/JDK-8367365
03-10-2025
If the the jstack and the thread dumps are examined at the instance of the jtreg timeout, there are various InnocuousThreads extant. So the 2 mins seems like insufficient time for the test mechanism (in the AgentServer) to fully complete it test termination and rendezvous back to the agent This test had a timeout of 8 minutes under the old timeout factor policy of 4, now it's 2 minutes with TIMEOUT_FACTOR=1.0 thus add a timeout=480 to coincide with its previous setting, but a lower timeout might be successful this has been structured as a junit test, junit should, by its nature be run in a pristine environment, as such, othervm would also be appropriate. This will avoid residue from previously executing tests in agentvm mode /timeout=240 ot 480 (as was previously used) and perhaps consider junit/othervm/timeout=240
02-10-2025