Ruediger Pluem schrieb:
>
>
> 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.
Yes, I think that's the question: if one CPING fails, what do you want
to do with the remaining connections in the pool?
- do you assume they are broken as well and close them directly (and
afterwards try to open a new one)
- do you want to test them immediately (and if one of them is still OK
maybe end the testing and use it)
- you don't care and simply try to open a new one.
Concerning the argument that the next connection on the step would be
even longer idle: yes, unless another thread returned one to the pool in
the meantime.
My personal opinion (based on mod_jk's connection handling code): CPING
failure is very rare. In most cases, it indicates connection drop has
happened by a firewall, in most remaining cases the backend is in a very
badly broken state. Both situations would result in nearly all remaining
connections would be broken as well, but not necessarily all (in the
firewall case, there might be less idle connections coming back from
other threads). So a good reaction to a CPING failure would be a pool
wide connection check and using a new connection.
If you are afraid, that the check of all connections in the pool takes
to long (maybe running into TCP timeouts), you could directly try a
fresh connection, and set an indicator in the pool, that the maintenance
task, which is usually only looking for idle connections to close,
should additionally do a function check for all connections. That would
be non-critical concerning latency for requests, once maintenance runs
decoupled from a request (like what Mladen suggested, either in a
separate thread or using the monitor hook).
Just my 0.2 Euro Cents.
> 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?
Unfortunately the AJP13 protocol is a little weak on connection
handling. There is no message indicating the backend shuts down its
connection. So it just closes the socket.
There is a message in the other direction, if the AJP client wants to
shut down a connection and inform the backend, but in mod_jk, and I also
assume in mod_proxy_ajp it is not used.
Regards,
Rainer
