On 09/05/2008 06:21 PM, Mladen Turk wrote:
Plüm, Rüdiger, VF-Group wrote:
+1 for the concept.
However for threaded servers you should call
ap_proxy_acquire_connection inside retry loop, cause there might
be available connections inside the pool.
I don't think that this does what you want. If I simply continue to
acquire connections from the pool without returning the faulty ones
back before, other threads might starve because they cannot get
connections
from the reslist any longer (not even faulty ones, that they would
reopen).
If I return the faulty connection to the reslist, there is some
likelyhood
that I get the same connection back within the next acquire as the
reslist
is organized as a stack. IMHO this approach would only work if the
reslist
was organized as a queue, which it is no longer in order to get the ttl
feature in conjunction with smax working correctly.
If failed each connection should be released anyhow, so it's a
loop operation that will either return connection with socket
(potentially valid), or without a socket for reconnect, in which
case you break from the loop in either case.
while (apr_proxy_acguire_connection) {
fresh = 0
if (conn->sock == NULL) {
fresh = 1
}
ap_proxy_determine_connection
ap_proxy_connect_to_backend
if (!ajp_handle_cping_cpong) {
CPING/CPONG failed. Mark the connection for closure.
conn->close++;
ap_proxy_release_connection
if (fresh) {
CPING/CPONG failed on fresh connection. bail out.
return 503;
}
}
else {
CPING/CPONG OK.
break;
}
}
go on with socket
As I said: Due to the fact that the reslist is a stack it results effectively
in the
same thing as my code does. This is because the acquire_connection call will get
the same faulty (but then closed connection) that the previous
ap_proxy_release_connection
placed back in the reslist.
Regards
Rüdiger
