JDK-8309069 : Test javax/management/remote/mandatory/connection/DeadLockTest.java timed out with Virtual threads
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 21,22
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows
  • Submitted: 2023-05-29
  • Updated: 2025-10-30
  • Resolved: 2025-10-30
Related Reports
Relates :  
JDK-8308352 - Test javax/management/remote/mandatory/connection/ConnectionTest.java timed out
Relates :  
JDK-8308985 - vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/TestDescription.java stuck during VTMS_transition_disable_for_all
Relates :  
JDK-8308366 - javax/management/remote/mandatory/loading/RMIDownloadTest.java timed out
Sub Tasks
JDK-8311190 :  
ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64 - Resolved
JDK-8370908 :  
Remove test javax/management/remote/mandatory/connection/DeadLockTest.java from ProblemList-Virtual - Resolved
Description
----------System.out:(3/99)----------
>>> test on a client notification deadlock.
>>> Test for protocol rmi
Timeout refired 480 times


Flags

    -Duse.JTREG_TEST_THREAD_FACTORY=Virtual \\
        -XX:-VerifyContinuations \\
Comments
Cannot reproduce - so, like e.g. 8308352, this Windows only Virtual thread timeout is likely the issue described in 8282726 (now fixed).
30-10-2025
Here's a log file snippet from the jdk-22+3-92-tier5 sighting: javax/management/remote/mandatory/connection/DeadLockTest.java #section:main ----------messages:(9/347)---------- command: main DeadLockTest reason: User specified action: run main DeadLockTest started: Thu Jun 15 20:17:04 UTC 2023 Mode: othervm Additional options from @modules: --add-modules java.management,java.management.rmi Timeout information: --- Timeout information end. finished: Thu Jun 15 20:27:52 UTC 2023 elapsed time (seconds): 648.132 ----------configuration:(3/66)---------- Boot Layer add modules: java.management java.management.rmi ----------System.out:(3/99)---------- >>> test on a client notification deadlock. >>> Test for protocol rmi Timeout refired 480 times ----------System.err:(0/0)---------- ----------rerun:(46/5798)*---------- <snip> result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-22+3-92\windows-x64-debug.jdk\jdk-22\fastdebug\bin\java' timed out (timeout set to 480000ms, elapsed time including timeout handling was 648126ms).
15-06-2023
Seeing occasional timeouts in several java/management tests, when jtreg is given use.JTREG_TEST_THREAD_FACTORY=Virtual There are tests which test connections which have been closed, to check they don't respond normally. These sometimes lockup and the test times out, when run from a Virtual Thread. Only seeing the problem on Windows, and occasionally. Cannot reproduce on demand. Is never a problem unless connect is called from a Virtual Thread. Looks like a reasonable match for: 8282726: java/net/vthread/BlockingSocketOps.java timeout/hang intermittently on older Windows releases in loom repo https://bugs.openjdk.org/browse/JDK-8282726 Windows Server 2016 and 2019 DeadLockTest.java: connections should stay alive for 1 second. env.put("jmx.remote.x.server.connection.timeout", "1000"); Connect. Wait 2 seconds. Call an operation on the Connection and ....lockup rather than exception is the problem. Creating a new Socket(host, port) uses a zero timeout. But when called in a regular thread, we always see the expected exception. When called in a Virtual Thread, on a connection we expect to fail, the connect does not always wake up (unpark) before the whole test times out.
06-06-2023