httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r1032345 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
Date Sun, 07 Nov 2010 19:24:00 GMT
On Sun, Nov 7, 2010 at 1:54 PM,  <trawick@apache.org> wrote:
> Author: trawick
> Date: Sun Nov  7 18:54:44 2010
> New Revision: 1032345
>
> URL: http://svn.apache.org/viewvc?rev=1032345&view=rev
> Log:
> mark connection for close after the return from
> ap_proxy_determine_connection()
>
> before this revision: if there was an existing connection,
> ap_proxy_determine_connection() would close it but then clear
> the close flag, so it didn't get closed by
> ap_proxy_release_connection()
>
> thus, if this child process doesn't use the connection for a
> while, the application could be stuck in read() for the same
> while
>
> after: ap_proxy_release_connection() will close it after the
> request completes
>
> Modified:
>    httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
>
> Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c?rev=1032345&r1=1032344&r2=1032345&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c (original)
> +++ httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c Sun Nov  7 18:54:44 2010
> @@ -961,13 +961,6 @@ static int proxy_fcgi_handler(request_re
>
>     backend->is_ssl = 0;
>
> -    /* XXX Setting close to 0 is a great way to end up with
> -     *     timeouts at this point, since we lack good ways to manage the
> -     *     back end fastcgi processes.  This should be revisited when we
> -     *     have a better story on that part of things. */
> -
> -    backend->close = 1;
> -
>     /* Step One: Determine Who To Connect To */
>     status = ap_proxy_determine_connection(p, r, conf, worker, backend,
>                                            uri, &url, proxyname,
proxyport,
> @@ -977,6 +970,12 @@ static int proxy_fcgi_handler(request_re
>         goto cleanup;
>     }
>
> +    /* XXX Setting close to 0 is a great way to end up with
> +     *     timeouts at this point, since we lack good ways to manage the
> +     *     back end fastcgi processes.  This should be revisited when we
> +     *     have a better story on that part of things. */
> +    backend->close = 1;

is the disablereuse flag more appropriate for indicating what should
happen with the connection once it is released?

is it practical and a reasonable idea for mod_proxy_fcgi to have a
different default for disablereuse than other scheme handlers?

hopefully something like this would work:

if (!worker->disablereuse_set) { worker->disablereuse = 1; }

disablereuse could be off for application processes which can handle
multiple concurrent requests AND can timeout idle connections after an
interval, but that isn't the typical FastCGI application.  For typical
FastCGI applications, an open connection from one httpd child process
would prevent it from being able to handle requests from other httpd
child processes.

Mime
View raw message