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 1.8.0.60 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
