A JMX server is started, and a JMX client connects to the server.
After the server stub is found, the client sends a request to get its connectionId, then the server stub answers that it cannot find ref object in its table to perform the request !
It is somewhat contradictory.
It could be a synchronization problem in the RMI stack (according ###@###.### who made an investigation to check if the race condition comes from JMX code side).
java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.getConnectionId(Unknown Source)
at javax.management.remote.rmi.RMIConnector.getConnectionId(RMIConnector.java:338)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:300)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:227)
at javasoft.sqe.jmx.test.perf_footprint.ConnectorClientPerfTest.test(ConnectorClientPerfTest.java:140)
at javasoft.sqe.jmx.test.perf_footprint.ConnectorClientPerfTest.run(ConnectorClientPerfTest.java:74)
at javasoft.sqe.jmx.share.TestStarter.<init>(TestStarter.java:40)
at javasoft.sqe.jmx.share.TestStarter.main(TestStarter.java:98)
Material to reproduce is all attached (see Comments).
Note that it occurs from time to time on some systems and never on some other systems (see Comments).
I agree that the test is a little hungrier than the average in terms of system resources and that the host where we reproduce the failure quite easy is not very powerful.
Both combined means two things : either the test is far too agressive, the RMI stack is overflowed and fails "safely", or the "pressure" put on the host allows to dig out a real race condition which could appear with virtually any system / any OS.
In case the former is true, the test should be modified; if the latter is true then it's a kind of robustness issue.
After the server stub is found, the client sends a request to get its connectionId, then the server stub answers that it cannot find ref object in its table to perform the request !
It is somewhat contradictory.
It could be a synchronization problem in the RMI stack (according ###@###.### who made an investigation to check if the race condition comes from JMX code side).
java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.getConnectionId(Unknown Source)
at javax.management.remote.rmi.RMIConnector.getConnectionId(RMIConnector.java:338)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:300)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:227)
at javasoft.sqe.jmx.test.perf_footprint.ConnectorClientPerfTest.test(ConnectorClientPerfTest.java:140)
at javasoft.sqe.jmx.test.perf_footprint.ConnectorClientPerfTest.run(ConnectorClientPerfTest.java:74)
at javasoft.sqe.jmx.share.TestStarter.<init>(TestStarter.java:40)
at javasoft.sqe.jmx.share.TestStarter.main(TestStarter.java:98)
Material to reproduce is all attached (see Comments).
Note that it occurs from time to time on some systems and never on some other systems (see Comments).
I agree that the test is a little hungrier than the average in terms of system resources and that the host where we reproduce the failure quite easy is not very powerful.
Both combined means two things : either the test is far too agressive, the RMI stack is overflowed and fails "safely", or the "pressure" put on the host allows to dig out a real race condition which could appear with virtually any system / any OS.
In case the former is true, the test should be modified; if the latter is true then it's a kind of robustness issue.