Hi. I hadn't had a chance yet to thank the various people here for
having the patience and persistence to explain to this dummy what must
be rather evident to experts.
I do so now, profusely.
It was very informative and rather clear.
I also gather that some of the details were not necessarily so evident
to the experts either, before they themselves went digging in the code.
I have read the Servlet Specs section 10. I can't say I enjoy it
particularly, the reason being that at just about every line it refers
to some probably basic Java or servlet server knowledge that
unfortunately I do not have yet, so it is sometimes to me rather
cryptic. It is so however, that the Specs plus your explanations
together really make this a lot easier to grasp.
Just one tiny aspect remains, no longer mysterious but just a bit hazy
still. It does have to do also with my lack of Java knowledge still.
Thus a servlet which is part of a webapp asks the Manager for it (the
webapp) to be undeployed. As a consequence, Tomcat no longer accepts new
requests for that webapp, and starts the process of stopping it and
undeploying it. If the webapp defined a ServletContextListener, this
"thing" 's ContextDestroy function will be called, once, by Tomcat, the
idea being that this is a warning like "watch it, you are being stopped
and undeployed". Tomcat basically does not care after that if the
webapp really does anything with the warning, but it waits a reasonable
time (some tens of seconds possibly) for any currently active servlets
of that webapp to have a chance to finish up and return. After this
time has passed, if any servlets of the webapp were still active, Tomcat
would forcefully kill them off (how it does that I don't know, but I
really don't need or want to know that).
What I still do not know is the following : suppose there are 3 active
servlets (processing requests) at the moment the request to undeploy is
issued by one of them. The servlet issuing the undeploy request knows
that it has asked for it, so it can take any appropriate measures to
terminate itself cleanly and quickly.
Which leaves the other two (I am using two intentionally, because there
is only one call to the ServletContextListener; it avoids cheating).
How do they know ? There must be something that the ContextDestroy
function does, which allows /both/ of these servlets to find out (if
they check) that they have only a limited time to live, and to hurry to
close themselves down properly, even if they would otherwise be busy for
another couple of minutes for instance.
Would that be like positioning some variable somewhere, accessible to
all the servlets belonging to that same webapp, which they can check
from time to time ? Or does one have to implement in each servlet some
kind of callback routine that the ContextDestroy can call ? (the Servlet
Spec section 10 doesn't mention that, so I guess this is not the case;
or it just assumes that whoever reads it is not a Java dummy and should
know this already).
And, does that tie into the fact that all the servlets of a same webapp,
by virtue of sharing the same classloader, can actually share something
? And, does that somehow relate to what the original OP of another
thread, who was talking about a "static variable" being set when Tomcat
is shut down, meant ? (despite the fact that I rather brashly sniped at
him for ditto).
Thanks
André
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 3/11/2009 6:33 AM, André Warnier wrote:
And if it asks to undeploy itself, is it not like pulling the carpet
from under its own feet?
It's more like asking a parent to pull the rug, but, yes, that's
basically what you're doing.
I mean, this webapp is running, and even
after asking the Manager to undeploy itself (meaning its whole shebang
of classes and libs will be erased from the disk), it should be able to
still stop itself cleanly. What if that requires a class that would
have to be loaded from its own WEB-INF/classes dir, which may not be
there anymore ?
When undeploying a webapp, no new requests will be sent to it, all
currently-processing requests are allowed to complete, and then a whole
series of things happen to take the webapp out of service. Consider
reading all of SRV.10 of the servlet specification. It's quite readable
(not legalese or mathematical proofs or anything) and gives you a lot of
good information.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm6cAwACgkQ9CaO5/Lv0PAOywCeOfRVhb+De+NraBwStFCOKc1u
8nMAnjYlh6jsjzKhiWZB60KwyyBkiNq8
=Rm3X
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
