On 10 March 2011 03:13, Thomas Guettler <[email protected]> wrote:
> Hi,
>
> From time to time one URL hangs, in my python code, since
> an other system is not available (not the fault of mod_wsgi).
>
> But this hanging page/url "eats" all request handlers. Sooner or later
> all request handlers wait for this hanging url. Other wsgi-application
> still work fine.
>
> My config:
>
> WSGIDaemonProcess modwork_foo_p user=modwork_foo_p group=modwork_foo_p
> threads=1 processes=8 maximum-requests=100
> WSGIScriptAlias /modwork
> /home/modwork_foo_p/modwork_foo/apache/django_wsgi.py
> <Location "/modwork">
> WSGIProcessGroup modwork_foo_p
> WSGIApplicationGroup %{GLOBAL}
> WSGIReloadMechanism Process
> </Location>
>
> What can I do to avoid this?
>
> If the timeout is set to e.g. 60 seconds, some other pages won't work, since
> they need longer.
Which timeout are you talking about?
If you are talking about inactivity-timeout then okay. If not, not
sure which one you are referring to.
The issue here now is that inactivity timeout applies to the whole
daemon process and not to specific requests. It is not possible to
apply the inactivity timeout to specific requests. I have looked at
the concept of implementing a request timeout, but it can't help where
the request is actually in a blocking operation because the only way
to implement it is by using injection of a Python exception into the
request thread from a background thread. When a request is in a
blocked call, such an exception will not interrupt it. Thus why
inactivity timeout on the whole process and killing it off when
blocked for too long is the only solution.
The result of this is that in order to apply a different inactivity
timeout applied to different requests, you will need to use multiple
daemon process groups and delegate different sub sets of URLs to
different daemon process groups. You would do this using:
WSGIDaemonProcess modwork_foo_p_1 user=modwork_foo_p
group=modwork_foo_p processes=1
WSGIDaemonProcess modwork_foo_p_2 user=modwork_foo_p
group=modwork_foo_p processes=8 threads=1 maximum-requests=100
inactivity-timeout=60
WSGIScriptAlias /modwork /home/modwork_foo_p/modwork_foo/apache/django_wsgi.py
WSGIProcessGroup modwork_foo_p_1
WSGIApplicationGroup %{GLOBAL}
<Location /modwork/suburl>
WSGIProcessGroup modwork_foo_p_2
</Location>
So, create two daemon process groups. The default global
WSGIProcessGroup would delegate to the main daemon process group. You
would then use Location directive to mark that requests for specific
sub URLs should go to the alternate daemon process group.
This allows you customise the properties of daemon process groups
specific to the requirements of different subsets of URLs. You can as
a result therefore set inactivity timeout differently for those URLs
which have a tendency to block.
BTW, note that in the above I have specifically used 'processes=1'.
Although a lot of people do use that option, they shouldn't and this
scenario above is the only time you should use it.
The reason it is important is that whenever you use the 'processes'
option, even if set to '1', the value of 'wsgi.multiprocess' is set to
True.
Under normal circumstances if only having the one daemon process group
and wanting a single process you don't want that to happen. This is
why you wouldn't normally use 'processes=1' because the result isn't
technically correct and will prevent browser debuggers such as
EvalException from working. Thus would normally leave off
'processes=1' and allow mod_wsgi to default to single process instead
and set 'wsgi.multiprocess' to False.
In the case above though we do want 'processes=1' because you are
spreading requests for the one application across multiple daemon
process groups. So, although one of those daemon process groups has
only one process, the application as a whole, ie., the combination of
all daemon process groups, uses multiple processes. Thus using
'processes=1' we get 'wsgi.multiprocess' being True, which is what we
do want.
Hope that all makes sense.
Graham
--
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.
