No servlet destroy() methods are being called at shutdown. The problem is that the stopServer method in Catalina.java constructs a new StandardServer and the digester.parse(is); on line 423 results in a call back to setServer which means that when the SHUTDOWN command is sent to the server, it actually goes to the new !started server.
Created attachment 8322 [details] There are several ways to fix this. IMO this is probably the tidiest!
This obviously works fine for me (I did test it again just to be sure). The stopServer method is run in a separate JVM, so there can't be any side effect ;-) Please reopen if you can submit a ready to test WAR (with source for the servlet, so that it can be debugged if needed). Thanks.
Sorry Remy. It was late last night. This happens when run with procrun (tomcat.exe) as a service. It runs in the same JVM. I haven't tested the patch but it should do the trick.
Bookkeeping, the previous comment looked loike an inadvertnet reopen
Ok. I'll try to be a bit more clear. This is a bug. I did mean to re-open. When running TC5 as a service with procrun (tomcat.exe) it calls stopServer within the same JVM that is currently awaiting resulting in the server object in Catalina being replaced with one that isn't started and therefore when stop is called it is called on the wrong object.
Sorry, nothing of what you say is true. Please do not reopen the report, it is bogus. I wasted about 1 hour on this, but there fixes which are needed to the shutdown routines (which could cause what you see, because the VM could die before completing the shutdown procedure properly), so it's good in some ways :)
Remy, I won't reopen it because you said not to, but I've debugged this. How can I prove it to you? Look at procrun_destroy_jvm in procrun.c. It calls jni_attach which: err = (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL); Stepping over line 423 in Catalina.java results in a callback to setServer and the Server object that stop gets called on is the same object. Just the fact that I can hit a break point at main in Bootstrap.java when I try to stop the service proves it. Because I'm attached to the JVM that the service started. I created the service with: C:\Tomcat\Home\bin\tomcatw.exe //IS//TomcatDebugServer --DisplayName "Apache Tomcat Debug Server" --Description "Apache Tomcat 5.0.12 Server - http://jakarta.apache.org/tomcat/ - Debug Server" -- Install "C:\Tomcat\Home\bin\tomcat.exe" -- ImagePath "C:\Tomcat\Home\bin\bootstrap.jar" --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java C:\Tomcat\J2SDK\jre\bin\server\jvm.dll --JavaOptions -server#-Xdebug#- Xrunjdwp:transport=dt_socket,suspend=n,server=y,address=53006#-Xms512m#- Xmx512m#-Xrs#-Dsp.log.suffix="_server1"#- Djava.endorsed.dirs="C:\Tomcat\Home\bin;C:\Tomcat\Home\common\endorsed"#- Dcatalina.base="C:\Tomcat\BaseServer1"#-Dcatalina.home="C:\Tomcat\Home"#- Djava.io.tmpdir="C:\Tomcat\BaseServer1\temp" --Startup manual --StdOutputFile C:\Tomcat\BaseServer1\logs\stdout.log --StdErrorFile C:\Tomcat\BaseServer1 \logs\stderr.log --Arguments "-config C:\Tomcat\BaseServer1\conf\server.xml" My problem is not that the JVM stops too early, it's that our webapp has some daemon threads that are running. They don't get interupted because destroy never gets called, therefore the service never stops.
Reopening to change status.
Your analysis is correct. That is exactly what is happening. This is fixed now in the CVS, and should appear in 5.0.13.
I couldn't reproduce the issue during testing with TC 5.0.12, and I couldn't find any issues affecting the shutdown code either. The only one is that apparently JDK 1.4 logging doesn't log reliably when called from a shutdown hook thread, for some reason. That made me think the proper shutdown didn't occur, but this isn't the case.
Tested as Fixed in nightly build. Cheers.