JDK-4476252 : Request for RMI socket TIMEOUT functionality, dynamic methods, etc
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.3_01
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2001-06-29
  • Updated: 2013-10-25
  • Resolved: 2013-10-25
Related Reports
Relates :  
JDK-8023862 - deprecate HTTP proxying from RMI
Relates :  
JDK-4476239 - (fmspec) Clarification needed on HTTP-tunelling info
Description
As of jdk 1.3, there is no way to avoid the direct TCP connection attempt.  
That is, even if user knows there's a firewall that will deny the direct 
connection, and client is started with -Dhttp.proxyHost and -Dhttp.proxyPort, 
the direct connection is still attempted, and only when it times out is the 
HTTP tunneling attempted.

This is a request to provide java properties so that one could set the RMI
TCP connection TIMEOUT value to a lower number than what is currently
provided by default. 

According to the jdk 1.3 RMI spec:
Calls transmitted via HTTP requests are at least an order of magnitude slower 
than those sent through direct sockets, without taking proxy forwarding delays
into consideration.

So why can't we proactively increase the performance, by providing a java
property (ex: -Djava.rmi.client.tcp.conn.timeout=xyz milliseconds), which lets 
users lower the RMI TCP connection time.

Furthermore, its extremely important that one could also set this above 
mentioned TIMEOUT dynamically on the fly. Its common for customer applications 
to probe for firewalls, proxy hosts, etc (through various means), and then lets 
say if the application senses a firewall and the availability of a proxy host, 
the application can then dynamically use a java rmi method and decrease the 
RMI TCP connection timeout value.

In some cases, based on end user input at installation time, or end user 
configuration of application, etc, the application might choose to avoid 
java RMI TCP connection attempts altogether. These attempts causes upwards 
of 1-2 minutes, in some cases. So there got to be a java property that can 
be set (ex: -Djava.rmi.client.disable.tcp.conn=true, and the default can be
set to false) at java RMI client start up time, to disable direct TCP
connection attempts altogether.

Equally important (actually more importantly), java rmi API needs to provide
methods/classes, so that one could dynamically disable java RMI client
doing any direct TCP connection attempts altogether.
Comments
A property already exists to control the timeout for direct socket connection, as noted above. HTTP tunneling has been deprecated by JDK-8023862, leaving direct socket connect as the only fully supported transport. It doesn't seem sensible to add a feature to disable it. Closing as won't fix.
25-10-2013
EVALUATION Note that Sun's RMI implementation supports the following system property for setting the timeout for the direct TCP connection attempt to a given host: -Dsun.rmi.transport.proxy.connectTimeout=X (where X is expressed in milliseconds) ###@###.### 2001-11-26 An additional implementation-specific property to disable the direct TCP connection attempt might be reasonable. Supporting dynamic changing of these properties would need to be investigated. ###@###.### 2002-07-15 Note that the v2.0 release of the Jini Technology Starter Kit includes an implementation of the Java RMI programming model, named Jini extensible remote invocation (Jini ERI), that provides much greater control over its transport layer, along with a standard HTTP-based transport implementation, which allows for (among other things) configuring the use of HTTP-based communication only: http://java.sun.com/products/jini/2.0/doc/api/net/jini/jeri/package-summary.html http://java.sun.com/developer/products/jini/ ###@###.### 2004-11-29 22:54:07 GMT
29-11-2004
PUBLIC COMMENTS As of jdk 1.3, there is no way to avoid the direct TCP connection attempt. That is, even if user knows there's a firewall that will deny the direct connection, and client is started with -Dhttp.proxyHost and -Dhttp.proxyPort, the direct connection is still attempted, and only when it times out is the HTTP tunneling attempted. This is a request to provide java properties so that one could set the RMI TCP connection TIMEOUT value to a lower number than what is currently provided by default. According to the jdk 1.3 RMI spec: Calls transmitted via HTTP requests are at least an order of magnitude slower than those sent through direct sockets, without taking proxy forwarding delays into consideration. So why can't we proactively increase the performance, by providing a java property (ex: -Djava.rmi.client.tcp.conn.timeout=xyz milliseconds), which lets users lower the RMI TCP connection time. Furthermore, its extremely important that one could also set this above mentioned TIMEOUT dynamically on the fly. Its common for customer applications to probe for firewalls, proxy hosts, etc (through various means), and then lets say if the application senses a firewall and the availability of a proxy host, the application can then dynamically use a java rmi method and decrease the RMI TCP connection timeout value. In some cases, based on end user input at installation time, or end user configuration of application, etc, the application might choose to avoid java RMI TCP connection attempts altogether. These attempts causes upwards of 1-2 minutes, in some cases. So there got to be a java property that can be set (ex: -Djava.rmi.client.disable.tcp.conn=true, and the default can be set to false) at java RMI client start up time, to disable direct TCP connection attempts altogether. Equally important (actually more importantly), java rmi API needs to provide methods/classes, so that one could dynamically disable java RMI client doing any direct TCP connection attempts altogether.
10-06-2004