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

[Daniel Fuchs]

On Thu, 23 Nov 2023 12:43:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> An exception here will prevent the class from being initialized...
>> 
>> Maybe we can break it, but this new property is following the same pattern I think as the neighbouring file src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java when it reads the system props.  I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us.
>> 
>> If there's more protection needed then we have various other places to apply it that might need separate follow-up if you think there's a case?
>
>> 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 :-)

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

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