This is a Fantastic request for Info. I am relieved to know there are some folks that can still frame a question in such a way to be a pleasure to read. Thanks, Ed
-----Original Message----- >From: André Warnier <a...@ice-sa.com> >Sent: Mar 13, 2009 12:04 PM >To: Tomcat Users List <users@tomcat.apache.org> >Subject: Re: Tomcat for Dummies > >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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
