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
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.