Catalina.stop: java.net.ConnectException: Connection refused: connect java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.<init>(Unknown Source) at java.net.Socket.<init>(Unknown Source) at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:410) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:336) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:427)
have the same problem. 10.4 server, ran a security update. now tomcat won't start, and when i run stop i get that "Catalina.stop: java.net.ConnectException: Connection refused". nothing else was changed/added, and nothing else seems to be running on 8080.
Jay, did you check if you have some other program running that already allocates port 8080? You can use a program like CurrPorts to see which programs have which TCP/IP ports allocated (on Windows). [ August 22, 2007: Message edited by: Jesper Young ]
Hi guys, same problem here. The port used (8082) is not busy with other app, startup is ok, I have to use Ctrl+C to shutdown. Shutdown.bat file does nothing 1st time, afterwards gives connect error. How did you solve it? Tx, JN
In Windows, if Tomcat was installed using apache-tomcat-6.0.16.exe [or a previous exe installer], during installation we should not check[select] the option service [ or something similar to NT service [NT/2k/XP only]].
If we had selected the option we may get "Catalina.stop: java.net.ConnectException: Connection refused: connect".
No, the service was already manual, but even after I removed it from a service, same happens. This is happening with Tomcat 5.0.30, Tomcat 5.5, and Tomcat 6.0. Using JDK1.5.0_12 or JDK1.6.0_04 is also the same. I checked the AJP ports (8009 and 8443) and they are free until Tomcat is started.
Another weird behaviour, and this might be a clue: I have problems with HTTP request and reponses, they start freezing after a while, either just after 1st request of JWS app or after 5 page refresh on simple Tomcat documentation page. The images start to not appear. This is similar behaviour to reported in this bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=35497 There is no answer, so I'll post it to the Tomcat user mailing list.
[ May 26, 2008: Message edited by: Jo�o Noronha ]
[ May 26, 2008: Message edited by: Jo�o Noronha ] [ May 28, 2008: Message edited by: Jo�o Noronha ]
I am having a very similar problem. Complete disclosure: I am a rank amateur, but my collaborator is incommunicado for the next week. We have Tomcat 5 on a Linux server running similar Web applications on two different ports. One, at the default port, is working fine. The other, at 9183, is not accessible through a Web browser. When I log in as root and try to start the uncommunicative Tomcat up, nothing appears to happen, but when I try to shut it down, I get,
Looking in various Internet posts about this error, I saw a suggestion to use netstat to see whether the port was already busy. Here is what I got:
The 22.214.171.124 is my own machine; I'm using it to SSH into the server machine. However, when I completely disconnect my machine from the server and instead SSH in from a different machine, the two connections remain, and I see two others from crawl-66-249-70-2.
From what I can understand on the Web, it's normal to have a few CLOSE_WAIT connections to a port. But they should disappear when I log out, right? So should I kill them? If so, how do I do that? [ December 18, 2008: Message edited by: Bob Grossman ]
Welcome to the JavaRanch. I would expect to get a "java.net.ConnectException: Connection refused" error from the shutdown script if Tomcat were not up and running. Since you can't connect with a browser, that deepens my suspicion. Try running "netstat -ap | grep 9183". That will tell you what PID is listening on that port. You can use "ps" to find out the executable. I'll bet it's not tomcat...
Thanks for your reply. I logged in as root and entered "netstat -ap | grep 9183", and no output was returned.
Yesterday, after posting my query, I fiddled around a bit and discovered that the CLOSE_WAIT connections in my previous post were created when I tried to use my browser to connect to 9183. I killed them manually, but it didn't solve my fundamental problem, which is that Tomcat is either not listening or not responding to browsers at that port.
Here's more information. If I run the startup script for the misbehaving Tomcat, then I run top, I see a ridiculously CPU-heavy Java process appear, like 95-98% CPU, and it does not go away over time. On the other hand, if I stop our well-behaving Tomcat instance and then restart it, a similarly large Java process appears, but it quickly goes away.
So it looks to me like the Tomcat startup process is hanging or entering an infinite loop. The whole port thing seems to be a red herring.
Here's the catalina.out log from a successful startup back in November:
and here it is from today:
No, the Context configuration file hasn't changed between then and now. I guess it's possible it's hanging up somewhere later in the process, before the last few successful executions have been written to the log. [ December 19, 2008: Message edited by: Bob Grossman ]
Over the weekend I was able to figure out what was going wrong.
The Catalina.stop message was a complete red herring. The problem was that Tomcat was entering an infinite loop when it started up. The infinite loop was inside a method called by a method called by a method called by a servlet method that was called only upon Tomcat startup.
Isolating the method that was causing the infinite loop was time-consuming, because Tomcat wrote to the log only up to the point that it called the servlet method; everything that happened once it entered the servlet method was invisible. So I needed to comment out various code, start up Tomcat, and use top to see if it entered the infinite loop (that 95% Java process I mentioned earlier). If it did, I used kill -9 to kill the Java process so I could comment out more code and restart again.
The infinite loop was caused by one misplaced variable. Unfortunately, nothing much was happening inside the loop, so it just kept going around and around without overflowing any buffer. Allowing this process to go unchecked seems like a flaw in Tomcat design to me.
Anyway, thanks to you who offered some help with this problem.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop