httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: mod_proxy, oooled backend connections and the keep-alive race condition
Date Fri, 02 Aug 2013 12:28:56 GMT
+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 <thomas.r.w.eckert@gmail.com> 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.
> 


Mime
View raw message