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.
