Hi -

Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a service (either 
via service.bat or the exe installer) on a Windows 7 64-bit OS, we are seeing 
an issue where the Windows shutdown kills Tomcat before our webapp shutdown 
sequence has time to execute fully.  (Specifically, we just want to make sure 
our instance of HSQLDB shuts down correctly, otherwise corruption can ensue.)

Details:

Initially we were running with 32-bit Tomcat 7.0.23 and saw that our shutdown 
sequence was not being logged at all when one of our customers shut down his 
laptop.  It looked like the process was just being killed.  I found a 
commons-daemon/procrun bug and corresponding fix that seemed like it should 
address the issue, namely 

http://stackoverflow.com/questions/13578196/how-to-gracefully-shutdown-procrun/14150785#14150785

https://issues.apache.org/jira/browse/DAEMON-274 

I subsequently upgraded Tomcat to 7.0.36 (32-bit, zip) to get the updated 
commons-daemon (http://tomcat.apache.org/tomcat-7.0-doc/changelog.html), but to 
no avail.  I thought perhaps the 32-bit Tomcat/64-bit OS might be a disconnect, 
so I installed the 64-bit version, but got the same result.  In short, it looks 
like we're either doing something wrong with our code, or there's a new wrinkle 
in the OS-service handshaking, or the bug wasn't fixed correctly...maybe in 
that order.

Details below on how our code manifested the problem as well as other steps to 
reproduce.

Our database shutdown code is located in the destroy() function of a class 
implementing org.springframework.beans.factory.DisposableBean.  I added a 
Thread.sleep(5 min) call to reproduce it on my machine.  As long as I shut down 
the service through the Services panel on Windows, the shutdown sequence fully 
executes (and takes 5 min, as expected).  But if I just shut down Windows, the 
sequence is interrupted.  

(As an aside, I don't expect the shutdown to take anywhere near that long in 
practice, but wanted to make sure the problem manifested itself so that I could 
address the bug.  We are seeing this with a decent customer test machine, but I 
can't reproduce it on my machine w/o changes.)

Thinking it might be Spring, I moved the shutdown delay to a 
ServletContextListener. contextDestroyed() method.  Same effect.

I moved the delay again, and reproduced the same problem in a standalone 
servlet that overrides HttpServlet.destroy().  I've posted the code at the link 
below:

http://pastebin.com/yYgrQ2sE

This is the output recorded in the stdout log file for an OS shutdown, and then 
a shutdown of the service by hand.  We, of course, favor the second. :-)

2013-03-14 10:05:40 Commons Daemon procrun stdout initialized
StatusServlet.init()
Entering StatusServlet.destroy()
Simulating long shutdown sequence.

2013-03-14 10:12:29 Commons Daemon procrun stdout initialized
StatusServlet.init()
Entering StatusServlet.destroy()
Simulating long shutdown sequence.
Simulation complete--sequence finished.
Exiting StatusServlet.destroy()

Can we guarantee that Windows won't just kill our Tomcat process and 
potentially corrupt our database?  That's the question.

I'd be grateful for some help on this.  Thanks for your time and attention.

Steve T
This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to