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

Mark Sheppard msheppar at openjdk.org
Thu Nov 23 11:40:05 UTC 2023


On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> RMI Connections (in general) 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.
> 
> src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> has other timeouts but nothing to control the initial Socket connect.
> 
> Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay.  Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout.
> 
> I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately.

The introduction of the system property is reasonable. I have questions over the veracity of the context described in the bug. I think it's a firewall configuration issue. If there is not listening end point for a TCP connect request, this will, result in a ConnectException being thrown in the RMI client. As such, for no response to happen, It means that a TCP connection has been established with the firewall (at the TCP level), from the RMI (JMX) client and that connection has not been accepted or passed through by the firewall application. Thus, it would appear that the shutdown of the target server has not been registered in the firewall.

In any case the change looks fine.
Do you have a test c.f. bug comment

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

PR Comment: https://git.openjdk.org/jdk/pull/16771#issuecomment-1824272681


More information about the serviceability-dev mailing list