JDK-8308352 : Test javax/management/remote/mandatory/connection/ConnectionTest.java timed out
  • 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-18
  • Updated: 2025-10-30
  • Resolved: 2025-10-30
Related Reports
Relates :  
JDK-8309069 - Test javax/management/remote/mandatory/connection/DeadLockTest.java timed out with Virtual threads
Sub Tasks
JDK-8311191 :  
ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64 - Resolved
JDK-8370955 :  
Remove test javax/management/remote/mandatory/connection/ConnectionTest.java from ProblemList-Virtual - Resolved
Description
----------System.out:(25/1437)----------
Testing for protocol rmi
Created connector server
Registered connector server in MBean server
Started connector server
Retrieved address: service:jmx:rmi://win2019-x64-518466/stub/rO0ABXNyAC5qYXZheC5tYW5hZ2VtZW50LnJlbW90ZS5ybWkuUk1JU2VydmVySW1wbF9TdHViAAAAAAAAAAICAAB4cgAaamF2YS5ybWkuc2VydmVyLlJlbW90ZVN0dWLp/tzJi+FlGgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AApVbmljYXN0UmVmAA8xMDAuMTAxLjE5OS4xOTEAAPterpn3sKkLebHikk3kAAABiC1OdneAAQB4
Authenticator returns: Subject:
	Principal: JMXPrincipal:  bar
	Principal: JMXPrincipal:  foo

Client connected
Got connection ID on client: rmi://100.101.199.191 bar;foo 1
Connection ID is OK
Server got notification: javax.management.remote.JMXConnectionNotification[source=d:type=server][type=jmx.remote.connection.opened][message=Connection opened]
Closed client
Got notification: javax.management.remote.JMXConnectionNotification[source=d:type=server][type=jmx.remote.connection.closed][message=Client connection closed]
Authenticator returns: Subject:
	Principal: JMXPrincipal:  bar
	Principal: JMXPrincipal:  foo

Second client connected
Second client connection ID is different
Server attributes received by client: {}
Server stopped
Server got connection-closed notification: javax.management.remote.JMXConnectionNotification[source=d:type=server][type=jmx.remote.connection.closed][message=Client connection closed]
Timeout refired 480 times
Comments
Cannot reproduce - so, like e.g. 8309069, this Windows only Virtual thread timeout is likely the issue described in 8282726 (now fixed).
30-10-2025
a question on one of the vmoptions associated with the failure -Duse.JTREG_TEST_THREAD_FACTORY=Virtual is this a jtreg property ?
08-06-2023
In a different set of bugs, it was mentioned that using virtual threads has been shaking out bugs where the test code failed to do a thread.join() on a test thread. With platform threads that's not an issue because the platform thread is not, by default, a daemon thread. However, with virtual threads they are daemon threads so the lack of thread.join() call can cause problems where the daemon worker thread doesn't prevent the VM from exiting like a non-daemon worker thread would do... Just a thought...
07-06-2023
[~msheppar] Right, no shortage of passing examples... Yes, "Server stopped" is shown after we call stop on the JMXConnectorServer, and we get a notification also. The following mbsc.getDefaultDomain() should fail fairly quickly... But it parks in the socket connect and is never unparked. > So is this the influence of the JTREG options use of virtual threads on processing ? Yes, no timeouts/lockups with all regular threads. > Also note that the test is run agentvm Wanted to test jtreg's main/othervm, but can't reproduce this at all so can't currently know if that helps.
07-06-2023
This test in the same tier5 test passes, different set of vmoptions "vmOptions": "-ea -esa -XX:-UseNotificationThread", https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-21+26-2273-tier5-20230606-0807-46905779-tier5-svc-UseNotificationThreadOff-open_test_jdk_jdk_svc-windows-x64-debug-913-1686040831-551/log ----------System.out:(31/1747)---------- Testing for protocol rmi Created connector server Registered connector server in MBean server Started connector server Retrieved address: service:jmx:rmi://win2016-x64-415146/stub/rO0ABXNyAC5qYXZheC5tYW5hZ2VtZW50LnJlbW90ZS5ybWkuUk1JU2VydmVySW1wbF9TdHViAAAAAAAAAAICAAB4cgAaamF2YS5ybWkuc2VydmVyLlJlbW90ZVN0dWLp/tzJi+FlGgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AApVbmljYXN0UmVmAA8xMDAuMTAxLjE5OC4yMTkAAMf4P0+kanMqxx0lkeqSAAABiI/NqoqAAQB4 Authenticator returns: Subject: Principal: JMXPrincipal: bar Principal: JMXPrincipal: foo Client connected Got connection ID on client: rmi://100.101.198.219 bar;foo 1 Connection ID is OK Server got notification: javax.management.remote.JMXConnectionNotification[source=d:type=server][type=jmx.remote.connection.opened][message=Connection opened] Closed client Got notification: javax.management.remote.JMXConnectionNotification[source=d:type=server][type=jmx.remote.connection.closed][message=Client connection closed] Authenticator returns: Subject: Principal: JMXPrincipal: bar Principal: JMXPrincipal: foo Second client connected Second client connection ID is different Server attributes received by client: {} Server stopped Server got connection-closed notification: javax.management.remote.JMXConnectionNotification[source=d:type=server][type=jmx.remote.connection.closed][message=Client connection closed] Connection correctly got exception: java.rmi.NoSuchObjectException: no such object in table New connection correctly got exception: java.rmi.NoSuchObjectException: no such object in table Testing for protocol iiop Protocol iiop not supported, ignoring Testing for protocol jmxmp Protocol jmxmp not supported, ignoring Test passed ----------System.err:(3/186)---------- Jun 06, 2023 8:23:21 AM com.sun.jmx.remote.internal.ClientCommunicatorAdmin restart WARNING: Failed to restart: java.rmi.NoSuchObjectException: no such object in table STATUS:Passed. While in the failed case the test gets the server stop but not the NoSuchObjectException Server stopped Server got connection-closed notification: javax.management.remote.JMXConnectionNotification[source=d:type=server][type=jmx.remote.connection.closed][message=Client connection closed] the process capture for the above might be informative for the failed case https://mach5.us.oracle.com/mdash/jobs/mach5-one-jdk-21+26-2273-tier5-20230606-0807-46905779/results?search=status%3Afailed%20AND%20-state%3Ainvalid%20AND%20name%3Ajavax%2Fmanagement%2Fremote%2Fmandatory%2Fconnection%2FConnectionTest.java extracts from https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-21+26-2240-tier5-20230602-1853-46781897-tier5-svc-virtual-open_test_jdk_jdk_jmx-windows-x64-debug-805-1685733176-177/artifacts/processes.html show server socket thread still extant and thus implies that the server hasn't stopped as is the expected call flow and two connection threads "RMI TCP Accept-0" #31 [24084] daemon prio=5 os_prio=0 cpu=0.00ms elapsed=518.49s allocated=8984B defined_classes=5 tid=0x00000264075e8210 nid=24084 runnable [0x00000083da3fe000] java.lang.Thread.State: RUNNABLE Thread: 0x00000264075e8210 [0x5e14] State: _at_safepoint _at_poll_safepoint 0 JavaThread state: _thread_in_native at sun.nio.ch.Net.accept(java.base@21-ea/Native Method) at sun.nio.ch.NioSocketImpl.accept(java.base@21-ea/NioSocketImpl.java:748) at java.net.ServerSocket.implAccept(java.base@21-ea/ServerSocket.java:698) at java.net.ServerSocket.platformImplAccept(java.base@21-ea/ServerSocket.java:663) at java.net.ServerSocket.implAccept(java.base@21-ea/ServerSocket.java:639) at java.net.ServerSocket.implAccept(java.base@21-ea/ServerSocket.java:585) at java.net.ServerSocket.accept(java.base@21-ea/ServerSocket.java:543) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi@21-ea/TCPTransport.java:424) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi@21-ea/TCPTransport.java:388) at java.lang.Thread.runWith(java.base@21-ea/Thread.java:1596) at java.lang.Thread.run(java.base@21-ea/Thread.java:1583) Locked ownable synchronizers: - <0x00000000d08a76c8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) Connection threads "RMI TCP Connection(2)-100.101.198.83" #35 [8884] daemon prio=5 os_prio=0 cpu=250.00ms elapsed=518.21s allocated=1741K defined_classes=142 tid=0x00000264075e9030 nid=8884 runnable [0x00000083da8fe000] java.lang.Thread.State: RUNNABLE Thread: 0x00000264075e9030 [0x22b4] State: _at_safepoint _at_poll_safepoint 0 JavaThread state: _thread_in_native at sun.nio.ch.Net.poll(java.base@21-ea/Native Method) at sun.nio.ch.NioSocketImpl.park(java.base@21-ea/NioSocketImpl.java:191) at sun.nio.ch.NioSocketImpl.timedRead(java.base@21-ea/NioSocketImpl.java:280) at sun.nio.ch.NioSocketImpl.implRead(java.base@21-ea/NioSocketImpl.java:304) at sun.nio.ch.NioSocketImpl.read(java.base@21-ea/NioSocketImpl.java:346) at sun.nio.ch.NioSocketImpl$1.read(java.base@21-ea/NioSocketImpl.java:796) at java.net.Socket$SocketInputStream.read(java.base@21-ea/Socket.java:1099) at java.io.BufferedInputStream.fill(java.base@21-ea/BufferedInputStream.java:291) at java.io.BufferedInputStream.read1(java.base@21-ea/BufferedInputStream.java:347) at java.io.BufferedInputStream.implRead(java.base@21-ea/BufferedInputStream.java:420) at java.io.BufferedInputStream.read(java.base@21-ea/BufferedInputStream.java:399) at java.io.DataInputStream.readFully(java.base@21-ea/DataInputStream.java:208) at java.io.DataInputStream.readInt(java.base@21-ea/DataInputStream.java:385) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(java.rmi@21-ea/TCPTransport.java:760) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(java.rmi@21-ea/TCPTransport.java:721) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda/0x000000080101b048.run(java.rmi@21-ea/Unknown Source) at java.security.AccessController.executePrivileged(java.base@21-ea/AccessController.java:778) at java.security.AccessController.doPrivileged(java.base@21-ea/AccessController.java:400) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(java.rmi@21-ea/TCPTransport.java:720) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@21-ea/ThreadPoolExecutor.java:1144) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@21-ea/ThreadPoolExecutor.java:642) at java.lang.Thread.runWith(java.base@21-ea/Thread.java:1596) at java.lang.Thread.run(java.base@21-ea/Thread.java:1583) So is this the influence of the JTREG options use of virtual threads on processing ? (ooh! bop-bop-bop they paved paradise to put up a parking lot) Also note that the test is run agentvm
06-06-2023
Similarly to: 8309069 Test javax/management/remote/mandatory/connection/DeadLockTest.java timed out with Virtual threads ..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
06-06-2023