-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 3/13/2009 12:04 PM, André Warnier wrote: > 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). It happens the other way around. Here is the chronology of events: 1. Undeploy process is initiated 2. New requests are disabled 3. Existing requests are completed (or time out? wasn't there someone this week complaining that TC will wait forever?) 4. All servlets are taken out of service (destroy() is called) 5. Session listeners are notified that sessions are dying 6. ContextListeners are notified the app is going down This prevents #6 from causing requests in #3 to fail due to any race conditions. > Which leaves the other two (I am using two intentionally, because there > is only one call to the ServletContextListener; it avoids cheating). The request to deploy the webapp was a loopback HTTP request to another webapp (the manager). This may or may not have been triggered by a client (HTTP) request. Yes, it's confusing. But by the time the undeploy actually starts, the thread that asked for the shutdown is almost certainly idle, having completed its request processing. > 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. See the chronology above. > 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). Heh. See SRV.2 for servlet information, and #4 above. > 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? They can also share data in the "application context" which is represented by the ServletContext object (and available to any request, filter, or servlet). > 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). I think he was asking if Tomcat somehow sets something somewhere (like globals.is_shutting_down) to indicate that the server is going down. The answer is: no, Tomcat doesn't do anything like that. It follows the servlet specification, which ... er, specifies how all components are to be notified that the webapp is going down. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm6ic0ACgkQ9CaO5/Lv0PD6tgCfcSIxjgNiWyQ/xlTDY7ak+z1c 5X4An3hjYxLaOjUSxefzyUCifYDh2aSI =W1W0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
