touch wsgi file resulting in existing requests to fail
sachin
to daemon mode to take advantage of being able to touch the wsgi file
to reload my app w/o having to stop/start Apache.
But when I update my code from subversion and then touch django.wsgi,
I've noticed that on the next request, the existing requests are
killed. My understanding was that the existing requests were supposed
to continue until they finished and then the new requests would get
the new code. But I have long-running requests that get killed after I
do the touch and on the first subsequent request.
I checked the error logs and I am getting the following errors (one
for each existing request that was killed midstream). These errors
occur exactly after touching the wsgi file and the first subsequent
request:
[Mon Nov 02 14:42:16 2009] [error] [client 174.129.20.60] Premature
end of script headers: django.wsgi
[Mon Nov 02 14:42:16 2009] [error] [client 174.129.20.60] Premature
end of script headers: django.wsgi
[Mon Nov 02 14:42:16 2009] [error] [client 174.129.20.60] Premature
end of script headers: django.wsgi
All the future requests seem to work fine, but the existing ones were
unexpected killed.
Any ideas?
Graham Dumpleton
>
> I am currently using mod_wsgi 3.04c. I just change from embedded mode
> to daemon mode to take advantage of being able to touch the wsgi file
> to reload my app w/o having to stop/start Apache.
>
> But when I update my code from subversion and then touch django.wsgi,
> I've noticed that on the next request, the existing requests are
> killed. My understanding was that the existing requests were supposed
> to continue until they finished and then the new requests would get
> the new code. But I have long-running requests that get killed after I
> do the touch and on the first subsequent request.
There is no graceful restart option for daemon mode processes. How
long it will wait for a long running request to finish is dictated by
shutdown-timeout option to WSGIDaemonProcess. See description of
shutdown-timeout in:
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
For a restarted triggered by touching the WSGI script file the timeout
defaults to 5 seconds.
Although you can increase this you have to be careful because handling
of any new requests will be delayed if all daemon process in a group
had to wait for full timeout or until active requests are completed.
This will impact the users perception of using the site.
Do note that when doing an Apache restart, graceful or normal, Apache
kills off the daemon processes even quicker, only waiting 3 seconds
and this timeout cannot be overridden as Apache doesn't provide a way
of doing so.
> I checked the error logs and I am getting the following errors (one
> for each existing request that was killed midstream). These errors
> occur exactly after touching the wsgi file and the first subsequent
> request:
>
> [Mon Nov 02 14:42:16 2009] [error] [client 174.129.20.60] Premature
> end of script headers: django.wsgi
> [Mon Nov 02 14:42:16 2009] [error] [client 174.129.20.60] Premature
> end of script headers: django.wsgi
> [Mon Nov 02 14:42:16 2009] [error] [client 174.129.20.60] Premature
> end of script headers: django.wsgi
>
> All the future requests seem to work fine, but the existing ones were
> unexpected killed.
>
> Any ideas?
Long running requests present problems for restarts, whether that be a
restart triggered by touching WSGI script file or when using
maximum-requests. In short, you can't easily support both.
My question is what are the long running requests doing?
Although it may be simpler to try and use one solution for handling
all requests, often long running requests really need to be dealt with
in special ways.
This may mean having special daemon process group with different
timeout settings and delegating URLs related to long running requests
to that separate daemon process group. Or, it may mean running such
requests under a hosting mechanism such that they can run
independently more easily. In some cases it may even be better to use
WSGI bridge on top of CGI, although the fact that web application
frameworks tend to be bloated does restrict you in as much as perhaps
needing to write a custom WSGI application for the specific purpose
required which isn't dependent on the bloated framework.
Graham