httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Behaviour of mod_proxy_ajp if CPING/CPONG fails
Date Fri, 05 Sep 2008 20:21:03 GMT

On Sep 5, 2008, at 10:21 AM, Plüm, Rüdiger, VF-Group wrote:

> IMHO the current behaviour of mod_proxy_ajp is not correct if a  
> CPING/CPONG fails
> on a backend connection. In this case the status is set to  
> HTTP_SERVICE_UNAVAILABLE
> and the scheme handler returns. In the case of an unbalanced backend  
> this results
> in a HTTP_SERVICE_UNAVAILABLE (503) to be returned to the client.  
> But a failing
> CPING/CPONG can be caused by a faulty AJP connection that was closed  
> by the backend
> or a race condition in sending the CPING and closing the connection  
> on the backend.
> So after the first failed CPING/CPONG we should try again with a new  
> TCP connection
> and should only return HTTP_SERVICE_UNAVAILABLE if this fails as  
> well. The following
> (and attached patch) does exactly that. Thoughs to the above and/or  
> to the patch
> before I commit?
>

I like error detection, but we are always fooling ourselves if we
think that we eliminate all race conditions by retrying... I ran
into this back when I was working on a HTTP/OPTIONS "cping/cpong"
for httpd. Although HTTP has other issues (like what to do with
keepalives and proxy settings for them, etc), the end result was
that even if the OPTIONS/cping succeeds, there is always the possibility
that the actual request will fail. So we should be robust on that
situation and respond in a way that is the least astonishing to the
client.

So I'm fine with retries, but it doesn't eliminate the possibility...
Mime
View raw message