True enough, but that's inelegant ;) On Aug 2, 2013, at 8:33 AM, Plüm, Rüdiger, Vodafone Group <[email protected]> wrote:
> 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. > > Regards > > Rüdiger > >> -----Ursprüngliche Nachricht----- >> Von: Jim Jagielski >> Gesendet: Freitag, 2. August 2013 14:29 >> An: [email protected] >> 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 <[email protected]> >> 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. >>> >
