httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: mod_proxy, oooled backend connections and the keep-alive race condition
Date Thu, 05 Dec 2013 16:07:07 GMT
On Thu, Dec 5, 2013 at 4:05 PM, Jim Jagielski <> wrote:

> There hardly seemed any consensus on the patch... It also
> seems that it adds more cycles to Apache on the front to
> reduce a race condition that can't really be removed.

I don't think more cycles are added by this patch.
What is done is that ap_proxy_http_request() is split in two functions,
the prefetch part is now in ap_proxy_http_prefetch(), and
ap_proxy_http_prefetch()+ap_proxy_http_request() has no more cycles than
the previous ap_proxy_http_request().
Unless you consider dereferencing pointer arguments a cycles-overhead
compared to using local variables...

I agree the race condition can't really be removed, mod_proxy can (must?)
strive for limiting it.
With this patch and the reslist's TTL below the backend's KeepAliveTimeout,
the race should not occur unless the backend closed before the timeout
(which may indeed be the case when, say, mpm_event is busy).

> IMO, a reverse proxy should get out of the way as
> quickly as possible.

I'm not sure to understand this but, IMHO, a reverse proxy should not
"reserve" a backend connection

(possibly) far before using it, and presume it will still be alive when
it's time to use it.

> Plus, if we do this here, shouldn't we do it for
> all proxy protocol submodules (fcgi, etc...)?


> Plus, as mentioned, this single patch includes 2 "fixes"
> which can be/should be independent.

This was just to show that "early prefetch" and "flushall" can work
together, but they are indeed 2 different things.
I can split them into different patches, should there be an interest in one
or/and the other.


View raw message