Connection timed out exception, why?

Question

I am developing an application which uses embedded tomcat server 7, and deploys a web application on embedded server.

My application accesses the embedded webapp through Rest APIs, but my clients are getting Connection Timed Out exceptions and port is also not blocked. I never gets this exception when I install this application on my local machine.

Some points:

• IP address is used in the host name part (They are able to access this IP address on other port)
• Port is not blocked
• We are using Apache HttpClient library to access the URL
• Timeout interval seems not to be an issue.

What are the possible reasons for this exception Connection Timed Out? or How can I simulate this problem on my local machine?

Any pointers would be helpful.

Answer 1

I'm just going to assume you are using Linux/Unix (includes telnet and netstat)... and that you run on port 8080. (Please edit your post, and add this info; and then if I guessed correctly, remove this notice on my answer)

Check that tomcat is listening as expected:

$ netstat -lant | grep 8080

(on Windows, can try the resource monitor you can find in task manager)

If you see 0.0.0.0:8080, then you are listening on all interfaces. If you don't see that port and "LISTENING" at all, then your tomcat is not listening.

If this is not working, check the server log (eg. tomcathome/logs/catalina.out) or tomcathome/conf/server.xml to see if the port is different. I find it common that the catalina.out has the answer (eg. maybe you ran it as a non-root user and port 80, which being <1024 isn't allowed in Linux/Unix)

Test it locally.

$ telnet localhost 8080
$ telnet <your ip here, not localhost or 127.0.0.1> 8080

(On Windows, I'm not sure what to try instead of telnet... you want something that will ignore redirections, sessions, authentication, etc. and just give you a raw simple answer; maybe use cygwin and the "curl -v" command) (to exit telnet, hit ctrl+] and then type "quit" and hit enter)

Test it remotely:

$ telnet <your ip here, not localhost or 127.0.0.1> 8080

If there are differences between the local test and remote test, examime the firewalls on all machines in between, including the server and client. (Linux clients generally don't block anything outgoing, but Windows 7 might)

And last but not least, run tcpdump:

$ sudo tcpdump not port 22

(tcpdump is also available for windows)

Then in another window, start the tomcat server, and then try to connect with a client to see what happens. (Others prefer wireshark or other tools; I'm probably the only one using the raw low level one)

And look for the port numbers in tcpdump's output. Try adding more conditions to exclude things you don't care about (eg. broadcasts, netbios, etc.... whatever else is running on the server; I excluded 22 so if you ssh in, you don't see your own ssh traffic spamming you) Some stupid application servers (eg. old Jboss versions) do terribly stupid things, making terrible assumptions, and try connecting on ports that aren't open (for mxbeans or whatever they are called) before they can even start listening, and sometimes fail because of it.