Re: [Resin-interest] handling site updates / redeployments
Thank you sir. I was hoping to find an inherent solution. Reloading apache's mod_proxy to a temporary page certainly works though. Anyone else have another solution? atomi. On 2/11/07, Daniel López <[EMAIL PROTECTED]> wrote: Hi, It might not be a very helpful hint, but one thing we have done is avoiding war files altogether, at least for our internal apps. We just use the exploded form and then we can update all the non-critical content without even a restart, but even if a restart has to occur, it is usually not that bad as they were when we used .war files. Moreover, what we also do is mod_proxy all our applications through Apache (yes, with a slight performance price) and when we need to do an upgrade that might be troublesome, like what you are describing, we simply redirect mod_proxy to a bogus location, which makes a nice Apache error page (that we can configure) to be displayed to the user; we upgrade; wait until it is fully up and then redirect mod_proxy again to the right host. If we had a cluster, we could handle it more gracefully, but we don't have that luxury :). Cheers! D. atomi escribió: > During a redeployment, there is certainly a period of downtime. In my > testing, while the application archive is being uploaded and expanded a > user will receive error code 500 java stack traces when trying to access > that virtual host or web app. > > My question is this: how are you guys handling redeployment downtimes > and 500 errors? > > A simple downtime.html page will do, but how would I set that globally - > meaning outside any virtual host and web app? Obviously any error-page > set inside a virtual host or web app will not work. My resin.conf is > very simple. > > > > http://host.name>}" > path="/srv/www/resin"> > > > > > > > > Thanks for any advice - I've been trying to solve this for days, > atomi ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] handling site updates / redeployments
Hi, It might not be a very helpful hint, but one thing we have done is avoiding war files altogether, at least for our internal apps. We just use the exploded form and then we can update all the non-critical content without even a restart, but even if a restart has to occur, it is usually not that bad as they were when we used .war files. Moreover, what we also do is mod_proxy all our applications through Apache (yes, with a slight performance price) and when we need to do an upgrade that might be troublesome, like what you are describing, we simply redirect mod_proxy to a bogus location, which makes a nice Apache error page (that we can configure) to be displayed to the user; we upgrade; wait until it is fully up and then redirect mod_proxy again to the right host. If we had a cluster, we could handle it more gracefully, but we don't have that luxury :). Cheers! D. atomi escribió: > During a redeployment, there is certainly a period of downtime. In my > testing, while the application archive is being uploaded and expanded a > user will receive error code 500 java stack traces when trying to access > that virtual host or web app. > > My question is this: how are you guys handling redeployment downtimes > and 500 errors? > > A simple downtime.html page will do, but how would I set that globally - > meaning outside any virtual host and web app? Obviously any error-page > set inside a virtual host or web app will not work. My resin.conf is > very simple. > > > > http://host.name>}" > path="/srv/www/resin"> > > > > > > > > Thanks for any advice - I've been trying to solve this for days, > atomi ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] handling site updates / redeployments
During a redeployment, there is certainly a period of downtime. In my testing, while the application archive is being uploaded and expanded a user will receive error code 500 java stack traces when trying to access that virtual host or web app. My question is this: how are you guys handling redeployment downtimes and 500 errors? A simple downtime.html page will do, but how would I set that globally - meaning outside any virtual host and web app? Obviously any error-page set inside a virtual host or web app will not work. My resin.conf is very simple. Thanks for any advice - I've been trying to solve this for days, atomi ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
