Why Does Java Rmi Keep Connecting to 127.0.1.1. When Ip Is 192.168.X.X

java.rmi.ConnectException: Connection refused to host: 127.0.1.1;

This is item A.1 in the RMI FAQ. You need to either fix your /etc/hosts file or set the java.rmi.server.hostname property at the server.

Java RMI connection to localhost at home network can't find correct remote module

See item A.1 of the RMI FAQ: specifically, 'The appropriate workaround is to set the system property java.rmi.server.hostname when starting the server.'

RMI Remote connection fails

As dave_thompson_085 said I was calling System.getProperty which was a typo that I completely missed. Calling System.setProperty corrects this problem and now works.

One of ehcache nodes mistakenly tries to connect to 127.0.0.1

After many hours of debugging in JDK and ehcache source codes I figured it out.

My core incorrect assumption was that something is wrong with Windows node where I see the error. Turned out it was linux node that supplies incorrect address.

Official Ehcache FAQ says:

This is caused by a 2008 change to the Ubuntu/Debian Linux default
network configuration. Essentially, the Java call
InetAddress.getLocalHost(); always returns the loopback address, which
is 127.0.0.1. Why? Because in these recent distros, a system call of $
hostname always returns an address mapped onto the loopback device,
and this causes Ehcache's RMI peer creation logic to always assign the
loopback address, which causes the error you are seeing. All you need
to do is crack open the network config and make sure that the hostname
of the machine returns a valid network address accessible by other
peers on the network.

Linux node was getting "127.0.0.1" in following method of class java.rmi.registry.LocateRegistry

public static Registry getRegistry(String host, int port, RMIClientSocketFactory csf) throws RemoteException
{
    Registry registry = null;

    if (port <= 0)
        port = Registry.REGISTRY_PORT;

    if (host == null || host.length() == 0) {
        // If host is blank (as returned by "file:" URL in 1.0.2 used in
        // java.rmi.Naming), try to convert to real local host name so
        // that the RegistryImpl's checkAccess will not fail.
        try {
            host = java.net.InetAddress.getLocalHost().getHostAddress();
        } catch (Exception e) {
            // If that failed, at least try "" (localhost) anyway...
            host = "";
        }
    }

    LiveRef liveRef = new LiveRef(new ObjID(ObjID.REGISTRY_ID), new TCPEndpoint(host, port, csf, null), false);
    RemoteRef ref = (csf == null) ? new UnicastRef(liveRef) : new UnicastRef2(liveRef);

    return (Registry) Util.createProxy(RegistryImpl.class, ref, false);
}

My Windows node was receiving it in following method of class net.sf.ehcache.distribution.ManualRMICacheManagerPeerProvider where it calls lookupRemoteCachePeer

public final synchronized List listRemoteCachePeers(Ehcache cache) throws CacheException {
    List remoteCachePeers = new ArrayList();
    List staleList = new ArrayList();
    for (Iterator iterator = peerUrls.keySet().iterator(); iterator.hasNext();) {
        String rmiUrl = (String) iterator.next();
        String rmiUrlCacheName = extractCacheName(rmiUrl);

        if (!rmiUrlCacheName.equals(cache.getName())) {
            continue;
        }
        Date date = (Date) peerUrls.get(rmiUrl);
        if (!stale(date)) {
            CachePeer cachePeer = null;
            try {
                cachePeer = lookupRemoteCachePeer(rmiUrl);
                remoteCachePeers.add(cachePeer);
            } catch (Exception e) {
                if (LOG.isDebugEnabled()) {
                    LOG.debug("Looking up rmiUrl " + rmiUrl + " through exception " + e.getMessage()
                            + ". This may be normal if a node has gone offline. Or it may indicate network connectivity"
                            + " difficulties", e);
                }
            }
        } else {
                LOG.debug("rmiUrl {} should never be stale for a manually configured cluster.", rmiUrl);
            staleList.add(rmiUrl);
        }

    }

    //Remove any stale remote peers. Must be done here to avoid concurrent modification exception.
    for (int i = 0; i < staleList.size(); i++) {
        String rmiUrl = (String) staleList.get(i);
        peerUrls.remove(rmiUrl);
    }
    return remoteCachePeers;
}

Official advice from Terracotta is to modify hosts file which seems too brutal to me. I concluded that it would be easier for Ops team to simply supply correct binding address in command line of my server which looks like this

java -Djava.rmi.server.hostname=192.168.10.128 -jar services.jar

java.rmi.ConnectException: Connection refused to host: 10.0.0.57

No I have not started the Registry.

Stop right there. You're not going to get anywhere until you start the Registry. You can't connect to something that isn't there.

It's strange that you're getting a connection timeout rather than 'connection refused', but there is nothing else here that needs explaining.

Setting java.rmi.server.hostname won't fix this problem. None of the questions you have cited here is a similar issue. They are all connection refusals in the client when executing a remote method. This is a connection refusal in the server when binding to the Registry.

---

Related Topics