Re: 1.1.20 with retry-patch

On Thu, 26 Feb 1998, Ming Lu wrote:

> After I put the retry-path, comm.c line 673 looks like this:
>
> if (status == COMM_OK) {
> lft = comm_set_fd_lifetime(sock, Config.lifetimeDefault);
> debug(5, 10, "comm_connect_addr: FD %d connected to %s:%d, lifetime %d.\n",
> sock, conn->ipaddr, conn->remote_port, lft);
> #ifndef RETRY_PATCH
> } else if (status == COMM_INPROGRESS) {
> lft = comm_set_fd_lifetime(sock, Config.connectTimeout);
> debug(5, 10, "comm_connect_addr: FD %d connection pending, lifetime %d\n",
> sock, lft);
> #endif /* RETRY_PATCH */
> }
> Is this right????

Yes. The retry patch tinkers with the connection timeout depending on how
many IP addresses are available to try, and the timeout ranges from the
full Config.connectTimeout down to Config.Retry.min_timeout. This is done
in the commBackoffTimeout() function. Thus, we don't want to set the FD
lifetime to a flat Config.connectTimeout seconds here in this function.

The reason for this is that if the connect timeout is 120 seconds, and
there's 15 addresses (like Microsoft, for instance), you would leave the
user hanging for 15 * 120 = 30 minutes while each of the 15 addresses
times out.

Instead, you divide 120 by 15, and wait 8 seconds for each IP address
attempt (assuming that 8 seconds is greater than or equal to
Config.Retry.min_timeout), yeilding a maximum wait-time of 120 seconds.

        -Mike Pelletier.
Received on Fri Feb 27 1998 - 06:50:27 MST