There are two ways to address this issue. One is described here in “Solution 1 – IPV4 Interface Metric”, the other in “Solution 2 – local hosts file”.
Long Connection Delays on Windows Platforms.
Solution 1 – IPV4 Interface Metric
This applies to LifeKeeper systems with more than one NIC connected to different subnets. Java’s RMI host lookup uses each interface’s IPV4 interface metric to determine the host IP address. In order to ensure that RMI communicates on the same network in both directions of a connection, the IPV4 interface metric should be specified so that a host’s public NIC has the lowest interface metric. This will ensure that the host’s public IP address will be reported.
By default, Windows network interfaces are configured with an “Automatic” interface metric. In some cases, this results in the wrong network being used for RMI communication between an LK GUI client and an LK host. The Automatic metric should be disabled, and an appropriate metric should be specified. For the public NIC, specify the metric “1”, for each additional NIC specify increasing metric values (2, 3, 4…).
Solution 2 – local hosts file
From Sun FAQ:
“Most likely, your host’s networking setup is incorrect. RMI uses the JavaAPI networking classes, in particular java.net.InetAddress, which will cause TCP/IP host name lookups for both host to address mapping and address to hostname. On Windows, the lookup functions are performed by the native Windows socket library, so the delays are not happening in RMI but in the Windows libraries. If your host is set up to use DNS, then this could be a problem with the DNS server not knowing about the hosts involved in communication and what you are experiencing are DNS lookup timeouts. If this is the case, try specifying all the hostnames/addresses involved in the local file\winnt\system32\drivers\etc\hosts or \windows\hosts. The format of a typical host file is:
IPAddress Server Name
e.g.: 18.104.22.168 homer.somecompany.com
This should reduce the time it takes to make the first lookup.”
In addition, incorrect settings of the Subnet Mask and Gateway address may result in connection delays and failures. Verify with your Network Administrator that these settings are correct.