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:[email protected]
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
