Bug 36976 - Tomcat VM does not shutdown with remote jmx enabled
Tomcat VM does not shutdown with remote jmx enabled
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Unknown
5.5.9
PC All
: P2 normal with 2 votes (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-10-08 13:01 UTC by Christian Elsen
Modified: 2009-03-06 13:36 UTC (History)
4 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Elsen 2005-10-08 13:01:14 UTC
When using tomcat with remote jmx it does not shutdown. Using it with local jmx
works perfectly.

jmx parameters set in catalina.bat as JAVA_OPTS
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=5555

Calling shutdown.bat I get the following error:

Error: Exception thrown by the agent : java.rmi.server.ExportException : Port
already in use: 5555;nested exception is:
    java.net.BindException: Address already in use: JVM_Bind

Tomcat keeps running instead of performing a clean shutdown.

JVM is a 1.5.0_04
Tomcat installation is a default from 5.5.9.zip without configuration changes
Comment 1 Sebastian Davids 2005-10-13 12:02:05 UTC
I'm experiencing the same.
Comment 2 Sebastian Davids 2005-10-13 15:04:25 UTC
Tomcat 5.5.12

Java HotSpot(TM) Server VM version 1.5.0_04-b05

VM arguments: 
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8081
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Operating System: 
Windows XP 5.1
Comment 3 Yoav Shapira 2005-10-17 00:42:25 UTC
Is there an additional stacktrace or part thereof in the logs?
Comment 4 Christoph Bachhuber-Haller 2005-10-17 16:06:27 UTC
(In reply to comment #3)
> Is there an additional stacktrace or part thereof in the logs?

There isn't. The reason why this is happening is that when tomcat starts, port
5555 (in this example) is bound. 

For shutdown, another jvm is launched and gets the same jmx parameters.
Therefore, it tries to bind to port 5555, too, fails and shuts the jvm down. The
shutdown procedure isn't executed and thus tomcat is still running.

The only fix I could think of is to introduce yet another variable that applies
to start and run but not to stop. 
Comment 5 Joshua Xia 2005-10-18 10:04:50 UTC
I reproduced this bug and agree Comment #4. Can we simply ignore JAVA_OPTS 
which introduce jmxremote parameters when stop the server?

I modified catalina.bat like the following and it works:

Index: catalina.bat
===================================================================
RCS file: /home/cvspublic/jakarta-tomcat-
catalina/catalina/src/bin/catalina.bat,v
retrieving revision 1.13
diff -u -r1.13 catalina.bat
--- catalina.bat	28 Apr 2005 12:32:05 -0000	1.13
+++ catalina.bat	18 Oct 2005 07:59:12 -0000
@@ -180,17 +180,33 @@
 rem Execute Java with the applicable properties
 if not "%JPDA%" == "" goto doJpda
 if not "%SECURITY_POLICY_FILE%" == "" goto doSecurity
+if %ACTION% == stop (
+%_EXECJAVA% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs="%
JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Dcatalina.base="%
CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%
CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+) else (
 %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs="%
JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Dcatalina.base="%
CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%
CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+)
 goto end
 :doSecurity
+if %ACTION%== stop (
+%_EXECJAVA% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs="%
JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Djava.security.manager -
Djava.security.policy=="%SECURITY_POLICY_FILE%" -Dcatalina.base="%
CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%
CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+) else (
 %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs="%
JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Djava.security.manager -
Djava.security.policy=="%SECURITY_POLICY_FILE%" -Dcatalina.base="%
CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%
CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+)
 goto end
 :doJpda
 if not "%SECURITY_POLICY_FILE%" == "" goto doSecurityJpda
+if %ACTION% == stop (
+%_EXECJAVA% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%
JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -
Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -
Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -
Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+) else (
 %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%
JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -
Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -
Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -
Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+)
 goto end
 :doSecurityJpda
+if %ACTION% == stop (
+%_EXECJAVA% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%
JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -
Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -
Djava.security.manager -Djava.security.policy=="%SECURITY_POLICY_FILE%" -
Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -
Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+) else (
 %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%
JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -
Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -
Djava.security.manager -Djava.security.policy=="%SECURITY_POLICY_FILE%" -
Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -
Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
+)
 goto end
 
 :end
Comment 6 Brian O'Rourke 2005-10-27 23:23:38 UTC
This affects all operating systems. Here's the simple catalina.sh equivalent of
Comment #5

--- apache-tomcat-5.5.12/bin/catalina.sh        2005-09-23 08:42:02.000000000 -0500
+++ catalina.sh 2005-10-27 16:12:58.000000000 -0500
@@ -266,7 +266,7 @@
     FORCE=1
   fi

-  "$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
+  "$_RUNJAVA" $CATALINA_OPTS \
     -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
     -Dcatalina.base="$CATALINA_BASE" \
     -Dcatalina.home="$CATALINA_HOME" \
Comment 7 Weili Shao 2006-01-19 23:35:39 UTC
Have the same problem and found this bug thread.  Tried patch in comment #6. 
Now the error message is gone when I am trying to shutdown the tomcat.  But the
tomcat process is still there and I have to manually kill it to restart tomcat.
 Seems the problem is not fixed yet.
Comment 8 Rainer Jung 2006-01-22 11:28:39 UTC
For most uses of JAVA_OPTS you have to make changes to catalina. sh to not use
all of the properties when shutting down. Consider the simple case, where you
adjust the size of your VM to e.g. 2GB. You then don't want the shutdown to
start a second VM with that size.

So there need to be two variables, one for start and stop use, one for
additional parameters in start use only.
Comment 9 Michael Vorburger 2006-07-17 16:07:59 UTC
Same expierence here... please get this fixed, suggested patches are here...

BTW: What's the difference between JAVA_OPTS and CATALINA_OPTS, anyway?  I
solved this by setting the com.sun.management.jmxremote.* stuff on CATALINA_OPTS
only, and then (as discussed above) commented out passing CATALINA_OPTS during
stop.  I found it "logical" to think that JAVA_OPTS are options passed to all
Java VM from catalina.sh/bat, but CATALINA_OPTS only to the actually started Tomcat.


PS: This "BindException: Address already in use" problem isn't limited to JMX;
doesn't the same - doesn't the same occur e.g. if a port for the debugger to
attach is used?  Or is that OK in the script and that's not passed on shutdown?
Comment 10 Manish sharma 2006-08-28 09:19:33 UTC
Tomcat does not shutdown properly.
It does not call the destroy method of the servelet that start on startup of 
tomcat.

Please verify
Comment 11 Mark Thomas 2006-10-08 12:18:38 UTC
I have applied the fix suggested in comment 9. From 5.5.21 onwards CATALINA_OPTS
will apply to start and run but not stop, JAVA_OPTS will apply to all 3.
Comment 12 Aaron Digulla 2007-01-17 06:59:01 UTC
The very same problem rears its ugly head when you use the Windows service which
comes with Tomcat 5.5.

Only this time, it's impossible to send different arguments to the VM via a
script because the "service-config-to-jvm" mapper handles this internally.
Comment 13 Aaron Digulla 2007-01-17 07:09:53 UTC
Sorry for the noise. I had a typo in my install script, so the command to stop
(on the Stop tab of the service editor) was "start" *ahem* ;-)

Now that I've changed it to "stop", the settings are filtered out and I don't
see an error in the logs anymore. And, what's more important, the service now
stops much faster...

This is with Tomcat 5.5.20
Comment 14 Patrick D. 2007-11-23 01:28:11 UTC
Still having the problem with Tomcat 5.5.23
jdk1.5.0_06
Linux System

Error: Exception thrown by the agent : java.rmi.server.ExportException: Port
already in use: 8092; nested exception is:
        java.net.BindException: Address already in use
Comment 15 Mark Beaty 2008-03-12 12:14:15 UTC
Is this issue fixed in Tomcat 6 (I'm using 6.0.13) per the stated resolution above? If so, I'm not seeing the changes. I still see both JAVA_OPTS and CATALINA_OPTS being used in start, run, and stop. Maybe I misunderstood the fix, so if someone could outline the fix more clearly, that would help. Thanks.
Comment 16 Rainer Jung 2008-03-12 13:59:30 UTC
The change was applied to 6.0 shortly after 6.0.14. Unfortunately 6.0.15 wasn't released and 6.0.16 has a serious bug. You can look at the pretty simple fix for the startup script under

http://svn.apache.org/viewvc?diff_format=h&view=rev&revision=558523

For TC 5.5 version 5.5.23 should have been the first official release with the fix.