RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

[Daniel Fuchs]

On Thu, 23 Nov 2023 17:14:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> IIRC, the default agent uses / may use its own socket factories - are we still coming here even with those factories?
>> 
>> We do get here, yes (not saying you can't customise your way out of getting here).  This is a stack from a test I was experimenting with, when it did see the timeout:
>> 
>> 
>> ---------System.out:(4/132)----------
>> JMX URL = service:jmx:rmi://x
>> expectTimeout = true
>> sun.rmi.transport.tcp.initialConnectTimeout = 1
>> Test passed
>> ----------System.err:(24/1791)----------
>> java.rmi.ConnectIOException: Exception creating connection to: x.x.x.x; nested exception is:
>>         java.net.SocketTimeoutException
>>         at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:637)
>>         at java.rmi/sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:217)
>>         at java.rmi/sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:204)
>>         at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:134)
>>         at java.management.rmi/javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:85)
>>         at java.management.rmi/javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2106)
>>         at java.management.rmi/javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:321)
>>         at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
>>         at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:229)
>>         at RMIConnectionTimeoutTest.main(RMIConnectionTimeoutTest.java:65)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>>         at java.base/java.lang.Thread.run(Thread.java:1570)
>> Caused by: java.net.SocketTimeoutException
>>         at java.base/java.net.SocksSocketImpl.remainingMillis(SocksSocketImpl.java:112)
>>         at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
>>         at java.base/java.net.Socket.connect(Socket.java:752)
>>         at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket(TCPDirectSocketFactory.java:57)
>>         at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>>         ... 13 more
>> STATUS:Passed.
>
>>  I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us.
> 
> Oh - right. It's `Integer.getInteger`, not `Integer.parseInt` Ok, then - I withdraw my first comment :-)

> This is a stack from a test I was experimenting with, when it did see the timeout:

Ah - that's for testing with a particular test. So the question now is:

Should the RMISocketFactories provided / implemented in the JMX implementation - such as those used by the JMX default agent, also honour this system property?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403620057