Rüdiger Plüm schrieb:
>
>
> 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.
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.
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.
So it seems you need a dequeue data structure to be able to reflect both
use cases.
Regards,
Rainer
