On Thu, 23 Nov 2023 17:14:52 GMT, Daniel Fuchs <dfu...@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
