Re: Feature request

I have a usleep-free flavor of this now. I found when I removed the usleep that it actually started misbehaving again. I was only modifying neighbor.c, when really I also needed to make a similar modification to forward.c. With the usleep in place it was giving enough time for forward.c's retry attempts (which is set at 10) to recover - more or less masking the issue.

So I do have this going without any usleep. The configuration parameter per peer sets the amount of time to retry connections when they fail - default is 0 to indicate this isn't wanted. It will basically ignore n_tries on FwdState if this is set, retrying up to X seconds. Generally speaking, 1 second is more than sufficient - almost makes me want to make it just an on/off switch but conceivably someone might want just a little longer.

I'm still not quite pleased with the way I'm implementing it, but at least now I have a definitive answer on the area of code that needs the improvements. I'd also rather make this a little more generic - perhaps an option when starting a connection in comm.c rather than only impacting peer connections (perhaps configurable at the peer level or globally, just in case someone experiences this problem in other areas aside from peers).

I won't put anything away yet. Since this is my first time to contribute I'd rather take my time to make sure I'm not going to screw something up.... :-) I'm also only modifying 2.5-STABLE1 on my machine at this time. If anyone wants to try it with 2.5 let me know, otherwise I'll keep it to myself for a few days.

BTW - should I subscribe to the squid-dev list at this point, or should I remain unsubscribed?

I also wanted to say that I was a bit hesistant to contribute at first, but everyone seems to have a good attitude about such things. I wasn't sure what I was going to get myself into - so thanks! :-)

-- Ray Cole

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 Sat Nov 02 2002 - 01:28:31 MST