Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

    java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
    java.net.ConnectException: Connection refused
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
    at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:128)
    at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
    at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
    at com.sun.proxy.$Proxy0.notifyMe(Unknown Source)
    at CallbackServerImpl.doCallback(CallbackServerImpl.java:149)
    at CallbackServerImpl.registerForCallback(CallbackServerImpl.java:70)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
    at sun.rmi.transport.Transport$1.run(Transport.java:177)
    at sun.rmi.transport.Transport$1.run(Transport.java:174)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:722)
    Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
    at java.net.Socket.connect(Socket.java:579)
    at java.net.Socket.connect(Socket.java:528)
    at java.net.Socket.<init>(Socket.java:425)
    at java.net.Socket.<init>(Socket.java:208)
    at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
    at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:146)
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
    ... 23 more
I get this exception when I try to connect a remote client to my server. In both, server and client the hostName for the registryUrl of rmi is the public IP address of the server. I also tried to put localhost in server but the error doesn't change. 
My java.policy is set to grant all connections to all ports and I have no firewalls enabled in the server or the client.
Any suggestions what could be?
                Please, how are you rsolved this problem ? i try with: java HelloServer -Djava.rmi.server.hostname=192.168.1.5 but the client cant' find the server  java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:     java.net.ConnectException: Connexion refusée
– researcher
                Dec 10, 2014 at 13:08
                @researcher And you also have to provide JVM arguments before the class name, not afterwards.
– user207421
                Feb 1, 2018 at 17:13
                the 'server' is the skeleton side on which the stub was originally created via .export; on the server side modify the implicitly stub embedded ip the client invokes: System.setProperty("java.rmi.server.hostname","1.2.3.4"); meaning this is the ip the destination/skeleton/server is approachable
– droid192
                May 1, 2018 at 11:21
                @PatrickBucher The person you mention only contributed a question. You should be thanking is me.
– user207421
                May 10, 2020 at 0:37
PROBLEM SOLVED
I had exactly the same error. When the remote object got binded to the rmiregistry it was attached with the loopback IP Address which will obviously fail if you try to invoke a method from a remote address. In order to fix this we need to set the java.rmi.server.hostname property to the IP address where other devices can reach your rmiregistry over the network. It doesn't work when you try to set the parameter through the JVM. It worked for me just by adding the following line to my code just before binding the object to the rmiregistry:
System.setProperty("java.rmi.server.hostname","192.168.1.2");
In this case the IP address on the local network of the PC binding the remote object on the RMI Registry is 192.168.1.2. 
                It does work when you 'try to set the parameter through the JVM', by which you presumably mean on the command line. If you use System.setProperty(), you have to set it before exporting the remote object, not just before binding.
– user207421
                Jun 25, 2015 at 23:41
                I was using the Naming.rebind() method before and got a similar error posed above. I changed it and followed your code suggestion, added the port number in my Naming.lookup(), my problem is then fixed. Thanks a lot!
– Lucky
                Dec 10, 2022 at 9:07
I found many of the Q&A on this topic, not nothing was helping me - that's because my issue was more basic ( what can I say I am not a networking guru :) ).  My ip address in /etc/hosts was incorrect.  What I had tried included the following for CATALINA_OPTS:
CATALINA_OPTS="$CATALINA_OPTS -Djava.awt.headless=true -Xmx128M -server 
-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=7091 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=A.B.C.D"  #howeverI put the wrong ip here!
export CATALINA_OPTS
My problem was that I had changed my ip address many months ago, but never updated my /etc/hosts file.  it seems that by default the jconsole uses the hostname -i ip address in some fashion even though I was viewing local processes.  The best solution was to simply change the /etc/hosts file.
The other solution which can work is to get your correct ip address from /sbin/ifconfig and use that ip address when specifying the ip address in, for example, a catalina.sh script:
-Djava.rmi.server.hostname=A.B.C.D
If you're running in a Linux environment, open the file /etc/hosts.allow
add the following line
Wildcards
Also check the /etc/hostname and /etc/host to see if there might be something wrong there.
I had to change my / etc / host from
127.0.0.1 localhost
127.0.1.1 AMK
127.0.0.1 localhost
127.0.0.1 AMK
also wrote in ALL in the file /etc/hosts.allow which was previously completely empty
Now everything works
do not know how safe it is. you have to read more about possible options for /etc/hosts.allow to do something that requires a touch of security.
                Thanks, I just modify /etc/hosts to point my localhost and hostname to the same ip, as you show, and now all works
– Davide
                Oct 30, 2019 at 11:34
                Oh but it would, observing it on my Archlinux box now. Creating the registry with LocateRegistry.createRegistry(1099) in my server class rather than getting it with LocateRegistry.getRegistry() solves the problem for me.
– alisianoi
                Jan 23, 2017 at 14:26
                It solves another problem. It solves 'connection refused' when doing the lookup. This problem is 'connection refused' when calling the remote method.
– user207421
                Sep 23, 2017 at 23:37
If you've tried modifying etc/hosts and adding java.rmi.server.hostname property as well but still registry is being bind to 127.0.0.1
the issue for me was resolved after explicitly setting System property through code though the same property wasn't picked from jvm args
                The Registry does not get bound to 127.0.0.1  If the system property didn't work from the command line you did it wrong.
– user207421
                Aug 17, 2014 at 12:29
I had the same exact problem and my issue was that I had 2 IP addresses from 2 different networks configured in the etc/hosts as below.
10.xxx.x.xxx    localhost
192.xxx.x.xxx   localhost
This should be because there was a conflict as to which IP to be used for the other devices to reach the rmiregistry over the network.
Once I removed the extra-record that is not required, I was able to solve the issue.
So my etc/hosts file had only the following record.
10.xxx.x.xxx    localhost
In my case I was unable to edit the hosts file because using a pc from the university.
I fixed the problem running rmiregistry in another port (instead of 1099) with:
rmiregistry <port>
and then running the server on that port.
It was basically an error caused by occupied port.
                If the port was already occupied you didn't get 'connection refused', and changing the Regsitry to another port didn't fix anything unless you also adjusted the code, and port 1099 was reserved for the RMI Registry by 1996, so whatever alleged process was allegedly already listening to it was severally non-compliant.
– user207421
                Oct 4, 2019 at 8:25
when you want to connect to remote server with RMI you must add a system property same as:
System.setProperty("java.rmi.server.hostname","Ip or DNS of the server");
or add environment variable.
For me I got Connection Refused and solve it by adding this line of code in server side:
 java -jar -Djava.rmi.server.hostname="ip or dns of the server" packageName.jar
Thank to other guy for guide me to solve it.
                There is no 'must' about it. It's only necessary with misconfigured DNS, or in some multi-homed host situations.
– user207421
                Sep 23, 2017 at 23:38
When I got the same error on my machine ("connection is refused"), the reason was that I had defined the following on the server side: 
 Naming.rebind("rmi://localhost:8080/AddService"
   ,addService); 
Thus the server binds both the IP = 127.0.0.1 and the port 8080.
But on the client side I had used:
AddServerInterface st = (AddServerInterface)Naming.lookup("rmi://localhost"
                        +"/AddService");
Thus I forgot to add the port number after the localhost, so I rewrote the above command and added the port number 8080 as follows:
AddServerInterface st = (AddServerInterface)Naming.lookup("rmi://localhost:8080"
                        +"/AddService");
and everything worked fine.
                This is not correct. The URL you use for the Registry does not determine what IP address the remote object is bound to. The IP bind has already happened prior to this code.
– user207421
                Dec 27, 2020 at 22:33
You can simply use:
on server side:
Registry <objectName1> = LocateRegistry.createRegistry(1099);
Registry <objectName2> = LocateRegistry.getRegistry();
on Client Side:
Registry <object name you want> = LocateRegistry.getRegistry();
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.