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...
