1
votes

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)
3

3 Answers

1
votes

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.

1
votes

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.

0
votes

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.