.. etc.. (sound of me being whacked ..)
no, no....no domestic violence here.... :-)
It's often hard enough to understand face to face, much less across
5000+ miles.
I think the following is a fair description ....Chuck & others should
nail me if it's not.
A webapp can be made up of one or more servlets, some of them
explicitly defined (in web.xml) and some implicit, such as the
servlets generated from jsp pages. At it's simplest, for each fresh
incoming request to the webapp, Tomcat determines the correct
corresponding servlet in the webapp, and then causes a (new or
recycled) thread to begin running that servlet with the incoming
request data (doGet or doPost, etc.).
Since multiple independent users might issue near simultaneous
requests, we can see that there might be numerous threads running for
the webapp, all started by Tomcat. (Also, each thread could easily
generate other child threads to run, so the park can get quite full of
picnickers.)
As Chuck pointed out, each webapp can have zero or more
ServletContextListeners defined for it. These are specified in the
app's web.xml like this (for example):
<listener>
<listener-class>com.myapp.listener.MyAppListener</listener-class>
</listener>
Then inside MyAppListener.java, one must have definitions of the
following two Java methods:
public void contextInitialized(ServletContextEvent
servletContextEvent) {....}
public void contextDestroyed(ServletContextEvent servletContextEvent)
{...}
The bodies of these methods can contain any (Java) code you like.
Tomcat guarantees that it will invoke contextInitialized as soon as
possible as it sets up the machinery for your webapp (either when
Tomcat itself has just started up) or when you have freshly deployed
or started the webapp. And Tomcat guarantees that as soon as possible
after learning that it must shut down the webapp, it will invoke
contextDestroyed.
There's no restriction on the number of such listeners which can be
specified for a webapp; you could have MyAppListener1, MyAppListener2,
etc.
Let's be frugal again and assume that there is just one listener
(MyAppListener). Then the contextInitialized method will be invoked
once when the webapp is started, and the contextDestroyed method will
be invoked only once when Tomcat needs to shut the webapp down.
As Mark pointed out, after Tomcat is told (say by the Manager) to
shutdown the webapp, Tomcat waits a certain interval (maybe 10
seconds) for currently running threads for the webapp to complete
processing. But after that interval, it invokes contextDestroyed /
just once/ no matter how many threads are still running for the
webapp. Presumably, if the webapp expects there to be such long-
running (possibly independent) threads still alive, the job (among
others?) of contextDestroyed would be to bring those threads to a
graceful halt.
I believe (but do not know -- Chuck, Mark??) that Tomcat essentially
creates a (new or recycled) thread in which to run contextDestroyed .
Cheers,
Ken
On Mar 11, 2009, at 1:13 PM, André Warnier wrote:
Ken Bowen wrote:
Let's be frugal and use just 2 "instances of a webapp".
How do you run "2 instances of a webapp"?
You must deploy them. How do you do that?
You drop a war file for each into webapps.
.. etc.. (sound of me being whacked ..)
Sorry, I expressed myself badly I guess.
I meant :
- there is only one webapp defined, say "/mywebapp"
- but there are currently 5 HTTP requests to "/mywebapp" being
processed
My understanding is that there are thus 5 Threads currently running
"mywebapp". That's what I was calling "instances", and I apologise
if that is the wrong terminology.
Now, one of these "instances", for some reason of it's own, has just
sent a request to the Manager webapp asking to be "undeployed".
Now, how many of these "ServletContextListener" things are in
existence, and how many are being called to say that something is
going on ?
Does my question/remark/puzzlement make sense in that context ?
Remember I'm not really a Java guy, so my understanding of these
things tends to be somewhat nebulous..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
