tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David kerber <>
Subject Re: Context destroy sequence of events
Date Mon, 14 Dec 2015 13:24:26 GMT
On 12/11/2015 4:36 PM, Mark Thomas wrote:
> On 11/12/2015 16:41, David kerber wrote:
>> On 12/11/2015 8:30 AM, David kerber wrote:
>>> Running TC 8.0.22 with JRE on Windows 2008 R2, as a windows
>>> service.
>>> Can someone point me to a reference that will tell me exactly what the
>>> sequence of events is when a servlet that is running as a windows
>>> service, is shut down?
>>> My situation is that my application receives data in a continuous stream
>>> and caches them for a period of time.  Then based on a couple of
>>> different triggers, it will write them to disk.
>>> What I need is a way to allow the windows service to be stopped in such
>>> a way that the servlet will not accept any more data while I flush my
>>> caches to disk.  This ensures that I don't lose any data during the
>>> shutdown (the remote clients that are sending the data will not move on
>>> to the next piece of data until they get the correct response from the
>>> server for the previous one).
>>> If I can ensure that (for example) the servlet will not accept any more
>>> connections when contextDestroyed event is triggered, but I will still
>>> be able to call my cache flushing routines, I think that would do what I
>>> need.
>>> Or if I can use the contextDestroyed event to set a flag in my
>>> servlet.doPost method to tell it to stop processing, that would work
>>> too.  Then I can call my cache flushing after that.
>>> Suggestions?
>> Is Servlet.destroy() the place for this kind of cleanup?
> Definitely not. In theory, a Servlet container can take any Servlet out
> of service any time it likes (as long as it is not is use) e.g. to
> reduce memory pressure.
> In a standard container stop the following happens (in this order, not
> exhaustive)
> - The connectors are paused so no new requests are processed
> - Existing requests continue to process
> - The Engine, Host and Contexts are stopped
> - The Contexts wait a configurable period of time for any running
> requests to finish (10s from memory although that might have changed)
> - contextDestroyed() is called
> So, the short version is call your flushing code from contextDestroyed()
> and you should be fine as long as you requests have finished. If they
> haven't, increase the wait time.

Thanks, Mark.  My requests only take a fraction of a second to process, 
so I should be good with the default wait time.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message