> On 30 Jun 2017, at 8:21 AM, Graham Dumpleton <[email protected]>
> wrote:
>
>>
>> On 30 Jun 2017, at 4:04 AM, John Hannon <[email protected]
>> <mailto:[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.
I may have got this bit a bit wrong as been a while since discussed this trick
with anyone.
You can't simply set a variable directly.
What you may actually have to do first is add:
WSGIProcessGroup %{ENV:PROCESS_GROUP}
and then ensure you set a default value for PROCESS_GROUP, but override it per
request when needed.
Example from docs at:
http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIProcessGroup.html
<http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIProcessGroup.html>
is:
RewriteEngine On
RewriteMap wsgiprocmap dbm:/etc/httpd/wsgiprocmap.dbm
RewriteRule . - [E=PROCESS_GROUP:${wsgiprocmap:%{REQUEST_URI}}]
WSGIProcessGroup %{ENV:PROCESS_GROUP}
You wouldn't use that approach as you don't need a mapping file, but hopefully
gives the right idea.
> 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.
