httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micha Lenk <mi...@lenk.info>
Subject Re: mod_proxy, oooled backend connections and the keep-alive race condition
Date Mon, 16 Dec 2013 20:33:41 GMT
Hi Yann,

Am 09.12.2013 00:30, schrieb Yann Ylavic:
>     Now, if trying to send the first bytes of the request immediately fails
>     because the socket isn't connected anymore (e.g. EPIPE), you *know* that
>     exactly *none* bits of your current request reached the server. For this
>     reason it should be safe to retry by establishing a new connection to
>     the server and to try to send the request again over the newly
>     established connection.
> 
> 
> The send() will never fail at this point if the peer FIN-closed the
> connection (EPIPE or whatever on non-unixes), since it is only half-closed.
> You can't read anymore, but you still can write, and this is precisely
> why the error log is "error *reading* status line" and not "error
> writing ...".
> A second send() could fail however, though possibly with ECONNRESET, and
> you are no better here.
> 
> The point is that mod_proxy already checks whether the connection is
> alive before trying to send a (successive) request on the kept alive
> connection, by using a recv(MSG_PEEK) (see ap_proxy_is_socket_connected).
> If that fails, a new connection is established and the request is sent
> on it, this is already the current behaviour.
> The race condition is when this check succeeds, but the peer closes the
> connection before the request reaches it (in the meantime).

Okay, got that. If it really works like it should then I don't know how
to improve the code. So the remaining question is, whether the checks
whether the connection is alive are sufficient. Unfortunately I have no
resources to investigate this any further.

Regards,
Micha

Mime
View raw message