Currently, at least with the default (client) socket factory, if a remote stub contains a host name instead of an IP address, the RMI/JRMP implementation only attempts to connect to the first (most preferred) IP address for that host name (according to the configured name service)-- but RFC 1123 says:

      When the remote host is multihomed, the name-to-address
      translation will return a list of alternative IP addresses.  As
      specified in Section 6.1.3.4, this list should be in order of
      decreasing preference.  Application protocol implementations
      SHOULD be prepared to try multiple addresses from the list until
      success is obtained.

It would seem appropriate to follow this recommendation for JRMP connection attempts.

Because the RMIClientSocketFactory.createSocket method returns a connected socket given only a string (that could be a host name) for host identification, one could imagine addressing this RFE in a couple of different ways:

[1] Modify the default (client) socket factory's implementation of createSocket to, when passed a host name, resolve it to a list of IP addresses (with InetAddress.getAllByName) and try connecting to each of them in order until a connection is established.

[2] Modify the JRMP implementation to do the same thing with the host string in a remote stub (when it is a host name) for any client socket factory, invoking createSocket on the socket factory for each connection attempt.

Even though [2] could provide the benefit of this RFE to some custom socket factories automatically, it could also break special host name processing done by other custom socket factories.  [1] seems to satisfy RFC 1123 at the right level (because RMICSF.createSocket takes a host string that can be a name or address) and does not perturb the existing socket factory interaction pattern.  

It seems that [1] is the right choice.  Custom socket factories can always implement this feature themselves (just as they can today).

N/A

Solution [1] seems like the right thing to do.
  xxxxx@xxxxx   2004-05-24

If solution [1] is implemented by modifying the default client socket factory, it would seem that javax.rmi.ssl.SslRMIClientSocketFactory should be similarly modified.
  xxxxx@xxxxx   2004-09-02