This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Frequently I am left with a running Tomcat instance after shutting-down the IDE. The Tomcat process has ben reparented to the "init" process (PID 1) and remains running until manually killed. This looks a lot like bugs 62456 and 63157, but is on Linux, not Windows. (Not saying it /is/ the same, just that it /looks/ the same.) Maybe related(?): Stopping Tomcat within the IDE from the buttons down the LHS of the Tomcat output window also frequently fails. Stopping it from the Runtime tab is the only reliable way of shutting down Tomcat.
*** This issue has been marked as a duplicate of 62456 ***
Reopenning, marked as a DUPLICATE by mistake.
I can't reproduce it. Did you start Tomcat from w/in the IDE? Externally started serves are not being stopped on IDE shutdown. Does the stopping Tomcat progress dialog pops up during the IDE shutdown? > Maybe related(?): Stopping Tomcat within the IDE from the buttons down the LHS > of the Tomcat output window also frequently fails. Stopping it from the Runtime > tab is the only reliable way of shutting down Tomcat. This sounds weird because the server output button and the server instance context menu action trigger the same code.
Tomcat is always being started from within the IDE (I wouldn't expect NB to shut down externally started apps). This happens intermittently (but more often than not). The "stopping Tomcat progress dialog" _does_ pop-up (but I have not been checking so closely to make sure that it does so consistently - will keep a closer eye on it).
The next time netbeans fail to stop tomcat, could you please check whether stopping it manually from the command line works or not? Just set the CATALINA_HOME and CATALINA_BASE environment variables and run the "$CATALINA_HOME/bin/catalina.sh stop" script.
Stopping Tomcat manually (after the IDE has shut down) also does not work, so this looks like an upstream (Tomcat) bug. I am used to this problem in the Tomcat 5.0.x line, but thought they'd solved this in the 5.5.x line - evidently not. Oct 17, 2005 3:51:27 PM org.apache.catalina.startup.Catalina stopServer SEVERE: Catalina.stop: java.net.ConnectException: Connection refused .... (FWIW, the "shutting down Tomcat" dialog did _not_ pop-up.) Random comments: My machine is under-resourced and pretty heavilly loaded with the IDE, Tomcat, browser, etc. Although I do try and minimize memory usage while doing this, the machine is swapping like crazy, so it looks to me like a timeout issue. Despite the likelihood of this being a Tomcat bug, is there not a way to work around it in NB? e.g. Don't assume that Tomcat has shut down by itself: check afterwards and forcibly kill the process if it has not shut down cleanly. Another point: This bug occasionally also manifests itself when trying to redploy a webapp (F6 within NB after changes, with Tomcat already running). It shows up as Oct 17, 2005 3:47:35 PM org.apache.coyote.http11.Http11Protocol start SEVERE: Error starting endpoint java.net.BindException: Address already in use:8084 indicating that the previously-running TC instance did not go away. :-(
From the error message it looks like the problem occurs when the stopping process is trying to send the shutdown command to Tomcat on its shutdown port. Aren't you aware of anything on your system, a firewall for example that might cause this? Could you please verify that the problem arises also when stopping Tomcat manually outside the IDE, without any previous attempt to stop it from within the IDE? This way we might verify that the bug is not in NetBeans. > Despite the likelihood of this being a Tomcat bug, is there not a way to work > around it in NB? e.g. Don't assume that Tomcat has shut down by itself: check > afterwards and forcibly kill the process if it has not shut down cleanly. Have you tried to select the "Force Stop" checkbox in the Server Manager Startup tab? This could probably work for you.
Closing as WORKSFORME since there is no farther response from the user.