0

How can I check the possible reason for java.net.SocketTimeoutException. I have a program that just pings to a website. however I am getting SocketTimeoutException. I know it is happening due to timeout expiring before the connection is established. But I want to know the precise reason of the issue. Like It is to do with internal DNS failure or due to unavailability of the internet or what !

Tried searching for similar questions but I didn't get the exact reason for not being able to establish the connection.

Below code snippet explains the problem

import java.net.HttpURLConnection;
import java.net.URL;

public class URLConnectionTest {

    public static void main(String[] args) {


        try {
            String urlString = "https://www.google.com";
            URL url  = new URL (urlString);
            
            HttpURLConnection con = (HttpURLConnection) url.openConnection();
            con.setConnectTimeout(5000);
            
            con.connect();
            
            System.out.println("Connected !!!");
        }
        catch(Exception e) {
            System.out.println("Error occurred while connecting" + e);
        }

    }
}

Now there are multiple outputs for different case.

  1. When I turned off laptop's wifi Error occurred while connecting java.net.UnknownHostException: www.google.com

  2. When I connect to wifi but router doesn't have the connectivity Error occurred while connecting java.net.SocketTimeoutException: connect timed out

Few lines of Stacktrace for Timeout

java.net.SocketTimeoutException: connect timed out at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)

  • Without sharing more detailed info this is all we can say, *Signals that a timeout has occurred on a socket read or accept.* – Themelis Jun 29 '20 at 10:38
  • Can you add the stack trace of the exception to the question? – Joni Jun 29 '20 at 10:52
  • Updated the question with code snippet and cases @Themelis – sadique urf arbaz Jun 29 '20 at 10:55
  • 1
    The first few lines of the stack trace would tell you if the exception happened while connecting or while reading – Joni Jun 29 '20 at 11:07
  • Yes, unfortunately exceptions during network IO are not very useful for correlating the reason to something the user might understand ("hey, you turned off the last network interface"). What exactly are you trying to do with that information? Maybe there's another way to get what you want. – Joachim Sauer Jun 29 '20 at 11:56
  • There is no ambiguity, contrary to what everyone is telling you. Given the stack trace, ***or*** given that you were only doing a connect, not a read, there is exactly one reason: the server didn't respond to the connect attempt within the timeout period. This would usually indicate a firewall problem: if the server wasn't running but was accessible it would have been a `ConnectException: connection refused`. – user207421 Jun 29 '20 at 11:56
  • Are you reffering only to his second error case @MarquisofLorne? – Themelis Jun 29 '20 at 12:04
  • @Themelis I am referring to the issue stated in his title. – user207421 Jun 29 '20 at 12:15
  • You're right @MarquisofLorne but he wants to know what went wrong in a lower level (as specified in my asnwer). For example in his 1st error case the server didn't respond since he has no connection but if he tries to connect to *iamnotawebsite.com*, with a valid internet connection, he will still get an `UnknownHostException`. – Themelis Jun 29 '20 at 12:20
  • @MarquisofLorne: of course there's ambiguity, you even say so yourself: "this would *usually* indicate a firewall problem". There's many *different* reasons why we got no reply within the timeout (which is different from the server not *sending* a reply, mind you). And that's exactly the problem: You get a low-level exception, but that doesn't tell you which user-actionable part needs fixing. – Joachim Sauer Jun 29 '20 at 16:23

0 Answers0