Re: Feature request

Yea, I agree with usleep shouldn't be in there. It may be about a week before I get a chance to get this in there. However if I remove the usleep, the change merely requires increasing PEER_TCP_MAGIC_COUNT. In my case I've made it configurable in my dev environment. The usleep is in there because it is likely if the current connection failed to the peer that the next few connections will as well. Obviously not necessary and it can be improved upon. I always get ECONNREFUSED from the connection in this situation until the peer has accepted the remaining connections.

Probably the best solution would be to configure the # of milliseconds to retry. Don't add a usleep, but instead add a check to see if we've retried the connection for more than X milliseconds.

I find that with the usleep in place I get up to 10 retries, so if I removed the usleep and went with making it some sort of connection retry timeout then I'd need something around a 20ms timeout. Or in my case I'd probably go with an even second just to be safe.

I promise I won't put anything in that blocks :-)

-- Ray

On Fri, 01 Nov 2002 07:26:44 -0600
Joe Cooper <joe@swelltech.com> wrote:

> Hi Ray and all,
>
> As a ringing endorsement of the addition of this or something like it to
> the official Squid, I'll mention that we've begun doing demo deployments
> in Africa through a reseller, and every location has a satellite
> connected proxy running on Windows machines...We have been consistently
> hitting these connection refused errors on about 10-15% of requests, and
> I hadn't been able to figure out why. May not be the same problem, but
> its worth a try.
>
> So, Ray, I'd be happy to give the patch some testing. But, I'd be leery
> of the nieghbors.c usleep...perhaps it should be configurable, as well,
> or made into an async operation. I'm sure an 'always on' blocking call
> like that would never get past Duane. He's a peer performance nazi.
>
> Ray Cole wrote:
>
> > I use squid on my Linux box to assist in communicating to a DirecWay
> > proxy server that resides on my Windows machine. It works great,
> > except for a little problem with Windoze. I tend to get a large
> > number of 'connection refused' errors when connecting to the proxy on
> > my Windoze machine. This is caused by the fact that Windoze doesn't
> > allow much of a backlog when listening for connections. I'm sure
> > you're well aware of these type of issues with Windoze.
> >
> > Fortunately if the connect attempt is retried it tends to work, but
> > sometimes requires a bit of a delay. I'm aware that squid retries up
> > to 10 times, but it doesn't put any delay in it. So if the machine
> > running the squid is considerably faster than its parent cache (which
> > it is in my situation) this immediate retry of 10 attempts isn't
> > sufficient.
> >
> > I made a modification to allow a new parent proxy configuration
> > option: retry-attempts=x, where x is the number of times to re-attempt
> > a connection to the cache. I modified cache_cf.c to support the new
> > command, structs.h to add a 'max_attempts' to the __peer structure,
> > and finally neighbors.c to use this max_attempts on tcp_up rather than
> > PEER_TCP_MAGIC_COUNT (10). 10 remains the default.
>
> --
> Joe Cooper <joe@swelltech.com>
> Web caching appliances and support.
> http://www.swelltech.com
>
Received on Fri Nov 01 2002 - 09:21:44 MST