httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rüdiger Plüm <r.pl...@gmx.de>
Subject Re: Behaviour of mod_proxy_ajp if CPING/CPONG fails
Date Fri, 05 Sep 2008 21:30:45 GMT


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

Mime
View raw message