[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: RFR: 8227337: javax/management/remote/mandatory/connection/ReconnectTest.java
From:       "Hohensee, Paul" <hohensee () amazon ! com>
Date:       2020-06-30 15:49:57
Message-ID: 295E28BE-DB14-4332-88F1-765BBB76BC5A () amazon ! com
[Download RAW message or body]

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@openjdk.java.net on behalf of daniil.x.titov@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


[prev in list] [next in list] [prev in thread] [next in thread]