On Tue, 28 Nov 2023 16:21:29 GMT, Kevin Walls <kev...@openjdk.org> wrote:
> JMX RMI Connections should use a timeout on the Socket connect call by > default. > > JMX Connections use RMI and some connection failures never terminate. The > hang described in 8316649 is hard to reproduce manually: the description says > it can be caused by a firewall that never returns a response. > > Changing the base RMI implementation may not be desirable at this time. > > JMX can use a new ClientSocketFactory for RMI which implements the connect > timeout, which can recognise a new JMX-specific property > `com.sun.management.jmxremote.rmi.tcpConnectTimeout` > (named like the existing com.sun.management.jmxremote... properties) > > Defaulting to a 1 minute timeout on connect has no effect on existing tests, > and should go unnoticed unless there really is a significant connection > delay. Specifying zero for the new System Property will use the old technique > of a connect with no timeout. > > This can be tested, but it is not realistically usable: although specifying a > 1 millisecond timeout will often fail (as expected/desired for the test), it > will very often pass as the connection happens immediately. Thanks, that's right it is a bad interoperability problem! The alternative SocketFactory needs to be available at all clients, so this is not workable. The other possibility was use of RMISocketFactory::setSocketFactory on the JMX client end. This lets us substitute in a preferred socket factory before making a connection, and one which can implement its own timeout. This is awkward as it affects the whole process. For JMX apps such as JConsole etc this is fine, but in other situations it may have side-effects on other RMI activity. At the moment the demand for the timeout is not strong, and the behaviour is what it has been for many years, so I am going to close this without progressing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16856#issuecomment-1835810085
