RFR: 8227337: javax/management/remote/mandatory/connection/ReconnectTest.java NoSuchObjectException no such object in table

[Daniil Titov]

Hi Paul,

Thank you for reviewing this change. You are right, in most test configurations test.timeout.factor is greater than 1.0.

Best regards,
Daniil

On 6/30/20, 8:50 AM, "Hohensee, Paul" <hohensee at amazon.com> wrote:

    The JBS issue is non-public, but this looks fine. I assume you set test.timeout.factor to something larger than 1.0 when you run MultiThreadDeadLockTest.

    Thanks,
    Paul

    On 6/29/20, 12:43 PM, "serviceability-dev on behalf of Daniil Titov" <serviceability-dev-retn at openjdk.java.net on behalf of daniil.x.titov at oracle.com> wrote:

        Please review the change that fixes an intermittent tests failure.

        The tests javax/management/remote/mandatory/connection/ReconnectTest.java and
         javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java  use
        specific settings for server timeout that in some cases  (e.g. when the test is run with -Xcomp)
         result in  JMX server connection timeout thread unexports the remote object while the client
         connection is still in the progress.  Below is an example of a such stacktrace:

        java.rmi.NoSuchObjectException: no such object in table
                at java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:303)
                at java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:279)
                at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
                at jdk.remoteref/jdk.jmx.remote.internal.rmi.PRef.invoke(Unknown Source)
                at java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl_Stub.getConnectionId(RMIConnectionImpl_Stub.java:318)
                at java.management.rmi/javax.management.remote.rmi.RMIConnector.getConnectionId(RMIConnector.java:385)
                at java.management.rmi/javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:347)
                at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
                at MultiThreadDeadLockTest.main(MultiThreadDeadLockTest.java:87)
                at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
                at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                at java.base/java.lang.reflect.Method.invoke(Method.java:564)
                at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
                at java.base/java.lang.Thread.run(Thread.java:832)



        The fix adjusts the server timeout  the tests use for "test.timeout.factor" system property.

        Testing: Mach5 tests are in the progress.

        [1] https://cr.openjdk.java.net/~dtitov/8227337/webrev.01/
        [2] https://bugs.openjdk.java.net/browse/JDK-8227337

        Thanks,
        Daniil