On 13 May 2010 02:23, btimby <[email protected]> wrote: > I just happened to read the release notes for version 2 of mod_wsgi: > > http://blog.dscpl.com.au/2008/03/version-20-of-modwsgi-is-now-available.html > > -- > Process Reloading Mechanism > > When using daemon mode of mod_wsgi and the WSGI script file for your > application is changed, the default behaviour is to now restart the > daemon processes automatically upon receipt of the next request > against that application. Thus, when making changes to any code or > configuration data for your application, all you now need to do is > touch the WSGI script file and the daemon processes for just that > application will be automatically restarted and the application > reloaded. This means that it is no longer necessary to send signals > explicitly to the daemon processes, or restart the whole of Apache. > This means that elevated privileges are not required by users and > applications owned by other users in a shared hosting environment will > not be affected when one users application is restarted. > -- > > So, touching the wsgi script will simply flag the app for restart. The > restart will occur on next request, thus no invalid response.
That isn't quite right. On a daemon process restart triggered by request subsequent to touching WSGI script, plus a restart due to user signal (SIGINT/SIGTERM) being received by process, plus a restart due to maximum-requests being reached, the process will shutdown immediately if there are no active requests. If however there are active requests then it will wait a maximum time before forcibly shutting down the process. By default this shutdown timeout is five seconds. Thus if, active requests have finished by then, they will effectively be aborted. Note that during that shutdown period, no new requests are accepted, so only existing requests that can be affected. Note that when daemon process being restarted due to Apache restart (be it graceful or not), then Apache parent sends a SIGINT and so above also applies, however, in that case Apache parent enforces a more forceful shutdown timeout in that it will only wait 3 seconds and that value cannot be changed as is a property of Apache itself and outside of mod_wsgi control. In mod_wsgi subversion trunk there is some new code for handling a semi graceful restart. For touching WSGI script file, behaviour will be the same as above, but in other situations like user signal, or maximum-requests being reached, you can now specify a graceful-timeout. This is a period which is inserted before the shutdown timeout period. In the graceful timeout period new requests will still be accepted, but at any point during the grace period the process becomes idle, it will shutdown immediately. If the process was getting sufficient requests that it was never idle or there were long running requests, then after the grace period the normal shutdown period would kick in with a forced abort of process if necessary. The new code also supports sending a graceful user signal for process restart. Thus you can send signal to trigger daemon process restart explicitly and have it be graceful about it. That is all I have time for right now to explain. Wll try and post again at some point as to your actual question of how to handle code upgrades without interrupting requests. Graham > That is one aspect of your question answered, I don't know what other > conditions might cause an invalid response, but 'kill -9' might :-). > > On May 12, 11:46 am, Aljosa Mohorovic <[email protected]> > wrote: >> i'm interested what kind of situations can cause mod_wsgi to return >> invalid responses or break current requests? >> what happens when i do "touch app.wsgi" after upgrade or some similar >> situation? does it break current requests? >> >> what i'm actually looking for is best practice tips for running, >> maintaining and upgrading a wsgi app. >> any guidelines/tips are appreciated. >> >> Aljosa Mohorovic > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
