-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Steve,
On 3/14/13 1:21 PM, Thomas, Steve wrote: > Thanks, Jeffrey. That may be a possibility for the long-term. > --Steve Did you read Jeffrey's entire reply? He started by top-posting, but then wrote some much more informative comments at the end of his post. - -chris > > -----Original Message----- From: Harris, Jeffrey E. > [mailto:jeffrey.har...@mantech.com] Sent: Thursday, March 14, 2013 > 12:52 PM To: Tomcat Users List Subject: RE: Procrun and Tomcat > service/OS shutdown on Windows > > Edit the registry so Tomcat depends on the HSQLDB shutdown. This > only works if HSQLDB is also started as a service. > > Jeffrey Harris > >> -----Original Message----- From: Thomas, Steve >> [mailto:stho...@vocollect.com] Sent: Thursday, March 14, 2013 >> 12:00 PM To: users@tomcat.apache.org Subject: Procrun and Tomcat >> service/OS shutdown on Windows >> >> 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 > > Edit the service entry in the registry (under > HKEY_Local_Machine\system\currentcontrolset\services\<Tomcat > Service Name>) so Tomcat depends on HSQLDB. This only works if > HSQLDB is also started as a service. If HSQLDB is started some > other way (i.e., by the Tomcat web app), you can try and install it > as a service using the srvany utility (or possibly the sc > utility). > > If you can configure Tomcat to be dependent on HSQLDB, this will > also force HSQLDB to start before Tomcat. > > There is a method discussed at > http://blogs.technet.com/b/askperf/archive/2008/02/04/ws2008-service-shutdown-and-crash-handling.aspx > that you might try. > > Finally you might also want to try delaying the shutdown timer on > the system to give Tomcat and/or HSQLDB more time to shutdown. It > might be possible that it is taking longer than the 12 seconds > Windows allows by default for a service to shutdown. That timer > can be changed at > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control > (WaitToKillServiceTimeout value; the data is in milliseconds). > However, Windows 7 and Windows Server 2008 R2 need a hotfix to > change this setting (see http://support.microsoft.com/kb/2549760). > > Jeffrey Harris > > This e-mail and any attachments are intended only for the use of > the addressee(s) named herein and may contain proprietary > information. If you are not the intended recipient of this e-mail > or believe that you received this email in error, please take > immediate action to notify the sender of the apparent error by > reply e-mail; permanently delete the e-mail and any attachments > from your computer; and do not disseminate, distribute, use, or > copy this message and any attachments. > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDeEUACgkQ9CaO5/Lv0PAdiQCgrHcAqArzfODuGUykJJbj3YIx ZE4AoKg8Ooju4DkHE/Wc74c3lh1NKvci =ArZV -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
