Java getInputStream SocketTimeoutException instead of NoRouteToHostException - java

I have an odd issue happening when trying to open multiple Input Streams (in separate threads) on Linux (RHEL). The behaviour works as expected on windows.
I am kicking off 3 threads to open https connections to 3 different servers. All three are invalid IP addresses (in this test case), so I expect an NoRouteToHostException for each of them. The first two return these as expected, and quite quickly. (see stack trace below) However the third (and 4th when I tested it that way) do NOT give a no route exception. They wait for ages, and then give a SocketTimeoutException (see other stack trace below). This takes ages to come back, and does not accurately express the connection issue.
The offending line of code is:
reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
Has anyone seen something like this before? Are there multi-threading issues with sockets on REHL or some limit somewhere to how many can connect at once...or...something?
Expected stack trace, as received for first two:
java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:559)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
Unexpected stack trace, as received on 3rd:
java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:559)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)

Is the linux firewall blocking the connect? If the output of iptables -L is populated that may contain your answer. You can also test by using telnet localhost <portnumber> to check if the port is available. If it is, telnet should say "connected", etc.

If the invalid IP address is blackholed, then no response will come back, and you will get a timeout rather than a "no route to host". The latter relies upon an ICMP error message being received back from the network.

Ah. see now I feel rather silly. Prompted from the responses above I decided to just put the ip addresses into the browser and see what happened. It turns out I was using the following IP addresses:
1.1.1.1
2.2.2.2
3.3.3.3
Unfortunately, 3.3.3.3 IS a valid IP address, which is not responding. So infact it was working fine all along.
I am now using proper non routable IP addresses 10.27.1.1 etc.

Related

JMX Connection time out

My Thread pool is becoming full because, most of the threads are waiting for the socket connection. How to add timeout for jmx connect
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
- locked <0x05671ad0> (a java.net.SocksSocketImpl)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:548)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:351)
at com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:71)
at javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:105)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:97)
at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:185)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1871)
at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1841)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257)
This is a tough one. It depends on which part is timing out due to the environment you are in.
Most probably you are encountering a connect timeout at the TCP level due either firewall issues or a dead application with its socket still up.
The overall connecttimeout for the JVM is set to -1, so infinite by default. Hello thread leaks.
sun.net.client.defaultConnectTimeout (default: -1)
You can find the documentation for Java oracle network parameters here: https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html
The jmx/rmi specific documentation sadly doesn't have a connect timeout setting at that level. But they have a bunch of other controls on the read time-out: https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/sunrmiproperties.html
You can test this while developing with something as simple as using netcat and pointing your app over to the localhost port:
# creat socket on port 3333
netcat -l 3333
# now point your app on the socket
# and you should be able to reproduce
This will stimulate a dead app or firewall block on the port.
Just add the Following System property - "-Dsun.rmi.transport.tcp.responseTimeout=60000"

NoRouteToHostException on client or server?

I am getting
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:564)
at sun.reflect.GeneratedMethodAccessor638.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:130)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
javadoc says
Signals that an error occurred while attempting to connect a socket to
a remote address and port. Typically, the remote host cannot be
reached because of an intervening firewall, or if an intermediate
router is down.
Is this error on client side or remote side or it can be either of these?
Basically it says that your client cannot connect to the server due to the address is inaccessible from the client machine.
Please check that the address you are connecting to is accessible, either via ping command in your Command Prompt (Windows) or terminal (Unix-based):
ping <address>
or if it's a web server you can try to check it in your web browser.
The ping command is helpful for me in most cases, since I would know why exactly I can't connect to the address. It can be a mistyped address or like the javadoc suggests, problem with firewall.
Either. It could be a firewall on the client machine blocking outgoing calls or somewhere at the other end.
It may be possible the ping will provide responses, but the application may still fail to connect.
If that is the case, I would suggest using telnet to try and connect to the host using the desired port, telnet host.address port
If the connection is refused then the port on the host will need to be allowed. It that succeeds, but the application still won't connect:
Verify the address:port being used in your application are the same as those used in the telnet test.
It may be a local port on the client blocking the connection, in which case you would need to allow the port on the client
In my case it was solved like this:
1 - Clear the cache with 'yarn cache clean' or 'npm cache clean --force'
2 - after that reboot the pc.
If you clear the cache but do not reboot, the data will still be stored 'somewhere' on the network, so the port will not connect, it is still busy.
After restarting it connects smoothly.
I hope I was helpful!
I had the same issue, and resolve it by disabling the firewall on both sides :
systemctl disable firewalld
service firewalld stop
I had the same issue, I did run iptables flush on host server, this fixed the issue.
# iptables --flush

Network is unreachable?

I want to run a cyc (opencyc) Java class, but when I run this class I got an error mentioning that the network is unreachable. I am working on NetBeans 7.0 and opencyc 2.0 win 32 version. I am using localhost (127.0.0.1) to test. The error is below.
Network is unreachable: connect
java.net.SocketException: Network is unreachable: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.<init>(Socket.java:366)
at java.net.Socket.<init>(Socket.java:180)
at org.opencyc.api.CycConnection.initializeApiConnections(CycConnection.java:223)
at org.opencyc.api.CycConnection.<init>(CycConnection.java:199)
at org.opencyc.api.CycAccess.<init>(CycAccess.java:121)
at org.opencyc.api.CycAccess.<init>(CycAccess.java:61)
at org.opencyc.api.ApiDemo.<init>(ApiDemo.java:50)
at org.opencyc.api.ApiDemo.main(ApiDemo.java:147)
Exception in thread "main" java.lang.NullPointerException
at org.opencyc.api.ApiDemo.<init>(ApiDemo.java:56)
at org.opencyc.api.ApiDemo.main(ApiDemo.java:147)
Interruption while waiting Cyc connection establishment, closing sockets
Exception in thread "Thread-1" java.lang.NullPointerException
at org.opencyc.api.CycConnection$TaskProcessorBinaryResponseHandler.access$002(CycConnection.java:988)
at org.opencyc.api.CycConnection.close(CycConnection.java:268)
at org.opencyc.api.CycConnection$ConnectionTimer.run(CycConnection.java:1351)
Why is this happening? How can I connect to the cyc?
The problem is that your network settings do not allow you to connect to this machine. This is not a Java problem as such.
try
ping {hostname}
until this works, there is nothing you can do in java to work around this.
If you have the same version I have, it's trying to establish a connection to a Cyc image with the hostname and port defined by
CycConnection.DEFAULT_HOSTNAME
CycConnection.DEFAULT_BASE_PORT
You can find the proper values to use by evaluating the following in your Cyc image:
(get-machine-name)
*BASE-TCP-PORT*
Hope this works for you.
A dev on my team encountered this today, only their machine is seeing this issue out of many on the team.
Through much debugging we eventually discovered that localhost would not resolve for some reason. It would work in some JVM contexts and fail in others so it was completely inconsistent.
Replacing localhost with explicitly 127.0.0.1 fixed the issue. My hunch is that something was different with a local network and IPv6 perhaps, but we still don't really understand why this is the fix.

Why connection to localhost is refused?

I have a server, to which a client machine connects. Recently I decided to encrypt the connection with stunnel, so now client program connects not directly to the server, but to localhost:8045 (I checked, and this port is not occupied).
Java code:
URL url = new URL("http://localhost:8045/malibu/GetProviders");
InputStream stream = url.openStream();
And I get the following:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.<init>(Socket.java:366)
at java.net.Socket.<init>(Socket.java:180)
. . .
If I try to request the same page using curl, everything is fine.
What can cause such behavior?
EDIT: Yes, there is a listening socket - running netstat -avn | grep 8045 gives:
tcp6 0 0 ::1:8045 :::* LISTEN
The listening socket is bound to the IPv6 loopback address (::1). I recall some issues with Java not supporting dual-stack IPv4/IPv6 systems correctly; this is probably such a case. It is connecting to 127.0.0.1 only (IPv4).
Everything else you have tried (curl, telnet...) will try the IPv6 address first, and then fall back on the IPv4 address if that fails. That's why they work, while the Java application does not.
Try forcing stunnel to bind to 127.0.0.1. You might also try having Java connect to http://[::1]:8045/malibu/GetProviders, though I can't recall if it supports IPv6 addresses in HTTP URLs.
I have Apache on Windows and also connection refused from Java. However debugging the connection and the Apache log shows, that it is actually not a connection problem. Apache returns error 301, permanently moved. Then it provides a redirection url to non-existing port 8080. So something's wrong with the server configuration, probably ServerName directive uses wrong port. Adding a trailing slash to the requested url fixes the problem. The most useful debugging output in my case was given by wget.
It's possible that the accepted answer does not explain the phenomenon. The reporter himself admitted in a comment that finally he used a url with slash at the end.

Java Socket Can't Connect to Own Computer

My program works just fine when I do
Socket s = new Socket("127.0.0.1", 10000);
But when I replace localhost with my own external IP adress, it fails
What gives? It throws an UnknownHostException immediately, even though I can ping my external IP just fine.
Stack trace:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at FileClient.main(FileClient.java:29)
What gives? It throws an
UnknownHostException immediately, even
though I can ping my external IP just
fine. Stack trace:
I don't see an UnknownHostException in your stack trace. The "remote" side actively refuses the connection. Could be because of a firewall, but unlikely, as firewalls usually silently drop packets instead of actively refusing. Most likely, the server application just isn't listening on the external interface. Most server software behave like that in the default configuration due to security reasons. Check what the output of the netstat -n -a command.
If that's your external IP you would need to open/port forward 100000

Categories

Resources