Try looking at your web servers custom error pages. Once the container is unavailable the web server is the only one that can process a request. Once the server goes down you will need to go with Laurie's said (good advice for any shop)
Bryan LaPlante ---------- Original Message ----------- From: Laurie Harper <[EMAIL PROTECTED]> To: user@struts.apache.org Sent: Wed, 22 Feb 2006 14:41:42 -0500 Subject: Re: error-page design question > Jay Burgess wrote: > > Our app currently throws a custom UnavailableException from a couple of > > places > > inside our Action handlers when the app is "offline" doing end-of-day > > processing. We thought we had this situation covered from the UI perspective, as > > we'd configured the following mapping in our web.xml: > > > > <error-page> > > <exception-type>UnavailableException</exception-type> > > <location>/unavailable.jsp</location> > > </error-page> > > > > However, our end-of-day processing now shuts down our web server, which > > causes > > the webapp to unload, and the unavailable.jsp to become inaccessible. The > > problem I've got is that if the user tries to access the webapp between the time > > it has started unloading and the time the web server goes down, instead of > > our > > unavailable.jsp, the user sees an ugly HTTP 500 error and a stack trace. > > > > What I'd like to do, as it affects the smallest amount of code, is something > > like the following: > > > > <error-page> > > <exception-type>UnavailableException</exception-type> > > <error-code>503</error-code> > > </error-page> > > > > That is, if the container catches the UnavailableException, generate a standard > > HTTP 503 error back to the browser. > > > > Is something like this possible to do in web.xml? (I don't see it in the > > DTD.) > > Or is my only option to catch the exception myself and do something like > > HttpServletResponse.sendError(SC_SERVICE_UNAVAILABLE) in the code? > > I think you're going to be out of luck there. The first thing the > container does when asked to undeploy a web application is to stop > forwarding requests to it... In other words, for the requests you're > interested in, there is nowhere you can place a 'catch'. > > You really need to either a) avoid shutting down the container, or b) > use some type of load-balancing or other HA techniques to switch request > processing to some temporary HTTP server before shutting down the > container, so you can guarantee that all requests are served by a > container that's in a consistent, live state. > > L. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ------- End of Original Message ------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
