I'm migrating an app from jboss 4.2 to wildfly 13. The app exposes EJBs, successfully migrated and these EJBs are used by some standalone clients (wrapped as services with tanuki wrapper) running on the same machine as wildfly. These standalone clients are monitored using JMX.
The startup code tries to unbind the service name in case the client crashed in an earlier run using
Naming.unbind("//localhost:1099/myService");
On normal startup (not after a crash) a
java.rmi.NotBoundException
is expected.
My issue is I get the following stacktrace
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.<init>(Socket.java:434)
at java.net.Socket.<init>(Socket.java:211)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
port 1099 is the default "well known" port as stated by the Naming javadoc:
The Naming class provides methods for storing and obtaining references
to remote objects in a remote object registry. Each method of the
Naming class takes as one of its arguments a name that is a
java.lang.String in URL format (without the scheme component) of the
form:
//host:port/name
where host is the host (remote or local) where the registry is located, port is the port number on which the registry accepts calls,
and where name is a simple string uninterpreted by the registry. Both
host and port are optional. If host is omitted, the host defaults to
the local host. If port is omitted, then the port defaults to 1099,
the "well-known" port that RMI's registry, rmiregistry, uses.
I also tried with wildfly management port as it uses http port upgrade, I get
java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
java.net.SocketTimeoutException: Read timed out
with the following root cause
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
at java.io.DataInputStream.readByte(DataInputStream.java:265)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:246)
What am I missing and/or doing wrong?
I found that the rmiregistry is not started by wildfly. I was mislead by our old environment that starts rmiregistry on OS startup by init.d.
So starting the rmiregistry solved my problem.
Rmi and wildfly http upgrade feature are not related to each other since rmiregistry is an independent process.
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?
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.
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.
you can use LocateRegistry such as:
Registry rgsty = LocateRegistry.createRegistry(1888);
rgsty.rebind("hello", hello);
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
ALL
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
to
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.
Maybe your rmiregistry not be created before client trying connect to your server and it would lead to this exception.In Linux, you can use "netstat" to check your rmiregistry be bond on the right port you assigned in java code.
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
It works for me after getting rid of "::1" in /etc/hosts.
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.
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.
On Windows make sure your Windows firewall is correctly configure / disabled. I had to disable the Windows firewall (because I didn't bother with configuring it) to get things to work even when I was testing with localhost.
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.
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();
This question already has answers here:
Official reasons for "Software caused connection abort: socket write error"
(14 answers)
Closed 7 years ago.
We have a Tomcat server that is in one case, responding to a web service and in another attempting to call a web service. In both cases the caller and end point are running on the local box. Yet there is a connection being lost and we know that it is not a network appliance.
Here are part of the exceptions:
The response:
Caused by: ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error
at org.apache.x.connector.OutputBuffer.doFlush(OutputBuffer.java:364)
at org.apache.x.connector.OutputBuffer.flush(OutputBuffer.java:326)
at org.apache.x.connector.Response.flushBuffer(Response.java:571)
And the call:
Caused by: java.net.SocketTimeoutException: SocketTimeoutException invoking http://localhost:7720/x/xService: Read timed out
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
The particulars:
Server version: Apache Tomcat/7.0.40
Server number: 7.0.40.0
OS Name: Windows Server 2008 R2
OS Version: 6.1
Architecture: x86
JVM Version: 1.7.0_25-b17
JVM Vendor: Oracle Corporation
Any ideas what might be causing this?
I should add that the server, once these errors occur, does not recover gracefully. It has to be restarted.
Well,since the whole log is not present the best guess I have is that either your port(7720) or url is incorrect or blocked locally (i.e being used by some other application) or the localhost entry in the hosts file is overridden and changed to something else instead of 127.0.0.1
When I call, the service's method, I have Web Service Exception happening which I couldn't figure out for now.
The issue is this, I am running NetBeans 6.8 against IIS 7.0 with the Web Service written using WCF:
javax.xml.ws.WebServiceException: java.net.SocketException: Connection reset
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:201)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:151)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at $Proxy30.getTwo(Unknown Source)
at HighBeamWcfClient.Main.main(Main.java:28)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:198)
How to fix it?
"Connection reset" typically means that someone/something between you and the server is resetting the connection or somehow blocking it. Check that you can connect to the server on the port correctly without any issue, and that there are no firewalls in the way.
A very simple test that you can connect to the port in question is to simply telnet to it with telnet serverhostname portnum, for example telnet stackoverflow.com 80.
I have a very simple rmi client / server application. I don't use the "rmiregistry" application though, I use this to create the server:
server = new RemoteServer();
registry = LocateRegistry.createRegistry(PORT);
registry.bind("RemoteServer", server);
The client part is:
registry = LocateRegistry.getRegistry(IPADDRESS, PORT);
remote = (IRemoteServer) registry.lookup("RemoteServer");
Here is the fascinating problem: The application works perfectly when both server and client are running in my (private) local network. As soon as I put the server on a public server, the application hangs for a minute, then gives me the following error:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.ConnectException: Connection refused to host: 192.168.x.y; nested exception is:
java.net.ConnectException: Connection timed out: connect
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source ... (the rest is truncated)
The key I think is that the client (running on my private network) cannot connect to myself (my address is 192.168.x.y where x.y is some other numbers, but the real error message shows my ip address listed there)
If I kill the rmi server on the public internet, then I instantly get a "connection refused to host: a.b.c.d") message, so I know that something at the server end is at least working.
Any suggestions?
EDIT: just to make this a little more clear: 192.168.x.y is the client address, a.b.c.d is the server address. The stacktrace shows the client cannot connect to the client.
Try running the server with this parameter for the virtual machine:
-Djava.rmi.server.hostname=hostname_of_the_server
192.168.* contains private IP addresses (as does 10.*). These will not be routed on the open internet. You need to make sure that you are using an public IP address for the server, and any firewalls (including NAT) are configured for access. You can do a quick check with telnet on the required port.
I would believe that the server tries to open a socket back to the client and it fails, and the exception is a bit unclear on its wording.
RMI is not very NAT-friendly, IIRC.