Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6411019

Race condition around a java.rmi.NoSuchObjectException: no such object in table ?

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: P3 P3
    • None
    • 6
    • core-libs
    • None
    • x86
    • linux_suse_sles_9.3

      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.

            peterjones Peter Jones (Inactive)
            yjoan Yves Joan (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: