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 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.

Reply via email to