> On 30 Jun 2017, at 4:04 AM, John Hannon <[email protected]> wrote:
>
> Hi Folks,
>
> I recently migrated a WSGI app from mod_wsgi 3.2-3.el6/Apache 2.2 to mod_wsgi
> 4.5.15/Apache 2.4.26.
>
> On the old server I was perpetrating this hack to support long connections if
> the request had 'refresh' in the path (I'm on an internet, not worried about
> abuse).
>
>
> SetEnv TIMEOUT=10
> SetEnvIf Request_URI .*refresh.* TIMEOUT=4800
>
> Timeout %{TIMEOUT}
>
> This hack no longer works. In fact, I've found that the Timeout directive has
> no effect on mod_wsgi unless it's declared in the 'server config' context.
> Apache's docs say Timeout is supposed to work in virtual host context as well.
>
> No idea if this is a mod_wsgi issue or an Apache issue, just thought I'd
> throw it out there.
As far as I am aware, it has never been possible to override Timeout value on a
per request basis. Part of the reason for that is that Timeout applies to a
connection and not a request. A connection can technically handle more than one
request because of keep alive connections. I would also suggest that a Timeout
of 10 is too short for typical case. For mobile clients you could see a higher
rate of failed connections. The default used to be 300, which is way too much.
A value of 30-60 is more typical.
The use of Timeout is also probably the wrong way of going about this anyway,
as it isn't a request timeout, but a timeout on individual read or write on a
socket connection to recover from situation where that operation would block
for some reason. Depending on how you are using mod_wsgi, if the blocking point
is in the request handler itself, then Timeout would never kick in as you
aren't blocked on read request content or writing response content.
With you being on latest mod_wsgi now, and can use all the latest features, I
would do what you are trying using the following.
1. Ensure you are using mod_wsgi daemon mode.
2. Vertically partition your WSGI application across multiple mod_wsgi daemon
process groups so that different configuration settings can be applied to each
daemon process group. This enables you to direct specific requests to different
daemon process groups and then customise timeout settings separately for
different request types. The general principal of vertical portioning is
explained in the post:
http://blog.dscpl.com.au/2014/02/vertically-partitioning-python-web.html
<http://blog.dscpl.com.au/2014/02/vertically-partitioning-python-web.html>
3. Use socket-timeout and request-timeout options on WSGIDaemonProcess to
customise timeouts for long running requests which would be directed to that
daemon process group. See:
http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html
<http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html>
4. Use SetEnvIf or mod_rewrite to set 'mod_wsgi.process_group' variable to the
name of the daemon process group which should handle the request with
customised timeouts.
Bit rushed for time right now, but see if you can come up with a configuration
based on that and will check over it for you.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
