On 09/06/2008 10:54 PM, Rainer Jung wrote:
Rüdiger Plüm schrieb:
On 09/05/2008 06:21 PM, Mladen Turk wrote:
Plüm, Rüdiger, VF-Group wrote:
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.
Maybe I'm missing something here:
The stack design is useful, because it allows for idle connections to
trigger the idle timeout. The most recently used connection gets reused
first.
Exactly.
But in case the user of the connection knows, that it's broken, and
closes it, it would make more sense to put in under the stack, since it
is no longer connected.
Why? IMHO this defers only the efforts that need to be done anyway to create
a new TCP connection. And keep in mind that even in the case that I put the
faulty connection back *under* the stack the next connection on top of the
stack was even longer idle then the one that was faulty. So it is likely to
be faulty as well. It might be the case though that this faultiness is
detected earlier (in the TCP connection check) and thus our next CPING/CPONG
in the loop happens with a fine fresh TCP connection.
One question as you are more familiar with the AJP server code on Tomcat side:
If a connector closes down a connection due to its idleness does it send any
kind of AJP shutdown package via the TCP connection or does it just close the
socket like in the HTTP keepalive case?
Regards
Rüdiger
