httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <>
Subject AW: mod_proxy, oooled backend connections and the keep-alive race condition
Date Fri, 02 Aug 2013 12:33:58 GMT
The typical way to solve this today is to know the keepalive timeout of the backend and set
ttl for this worker to a value a few seconds below.



> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski 
> Gesendet: Freitag, 2. August 2013 14:29
> An:
> Betreff: Re: mod_proxy, oooled backend connections and the keep-alive
> race condition
> +1 for the theory, but I'm not sure if it's feasible or not.
> On Aug 2, 2013, at 5:28 AM, Thomas Eckert <>
> wrote:
> > So I've been seeing lots of "proxy: error reading status line from
> remote server" by mod_proxy lately. Usually this is caused by the race
> condition between checking the connection state and the backend closing
> the connection due to the keep-alive timeout. As Covener pointed out to
> me in IRC, using mod_proxy_http's env variable "proxy-initial-not-
> pooled" does offer a solution to the problem albeit at the cost of
> performance.
> >
> > The call to ap_proxy_http_process_response() in mod_proxy_http.c
> eventually boils down to ap_rgetline_core() which calls ap_get_brigade()
> on r->input_filters. This looks to me like a simple input filter might
> do the trick if it only checked for a possibility to read on the socket
> and reopens the connection upon failure type "reset by peer". I took a
> short look at core_create_proxy_req() in server/core.c to see how
> connections are set up and I wonder if it's possible to recreate/reuse
> that logic in an input filter. If so, this input filter would offer a
> nice alternative if hard coding this behavior into mod_proxy/core is
> frowned upon. Simply make the filter dependant on an env variable, just
> like proxy-initial-not-pooled.
> >

View raw message