Re: ICAP connections under heavy loads

Bump.

I was wondering if there was any progress about this matter?

Thanks,
Eliezer

On 9/11/2012 5:00 PM, Alex Rousskov wrote:
> On 09/10/2012 05:51 PM, Amos Jeffries wrote:
>> On 11.09.2012 03:06, Alex Rousskov wrote:
>>>>> Here is the sketch for connect retries on failures, as I see it:
>>>>>
>>>>> default:
>>>>> ++failRetries_; // TODO: rename to failedTries
>>>>>
>>>>> // we failed and have to start from scratch
>>>>> ... close the temporary socket ...
>>>>>
>>>>> // if we exhausted all retries, bail with an error
>>>>> if (failRetries_ > Config.connect_retries) {
>>>>> ... send COMM_ERR_CONNECT to the caller ...
>>>>> return;
>>>>> }
>>>>>
>>>>> // we can still retry after a small pause
>>>>> // we might timeout before that pause ends, but that is OK
>>>>> eventAdd("Comm::ConnOpener::DelayedConnectRetry", ...)
>>>>>
>>>>> More changes would be needed to make this work correctly:
>>>>>
>>>>> * the timeout handler should not be associated with the socket
>>>>> descriptor (since it may change). We can use eventAdd instead.
>>>>>
>>>>> * the Comm::ConnOpener::DelayedConnectRetry() wrapper should call a
>>>>> method that will open a new socket.
>
>>>> Sounds okay to me.
>
>> I'm not strongly viewed on this, but is it better to display a hard
>> ERR_CONNECT or a soft(er) TIMEOUT in these cases? ie is it actually a
>> good idea to remove the timeout if case?
>
> The timeout handler will trigger ERR_TIMEOUT. The system call error
> handler (pictured above) will trigger ERR_CONNECT. Different cases,
> different errors. Personally, I do not assign hard/soft qualifiers to
> those two errors. Do existing Squid callbacks care?
>
>
> Thank you,
>
> Alex.
>

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
sip:ngtech_at_sip2sip.info
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il