On Thu, 23 Nov 2023 12:43:33 GMT, Kevin Walls <kev...@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
