> Yeah, this came up in another bug as well, don't remember where, but > really this whole section needs to be reworked pretty extensively; > this is just a way to fine-tune the current behaviour until we figure > out what the right thing to do should be (and I suspect that's not a > trivial task). > > BTW, it's not exactly as you describe; it's not 10x attempts per > route, it's 10 routes, AFAICT.
Aokay, squid-2 is a little different again then to what I'm seeing in -3. There its 10x one route, or 1x any IP route, or something involving rotating IPs and ResetFD I didn't grasp well enough to describe intermixed with connection-level retries I think connected to the peer routes somehow through a maze of functions. Amos > > Cheers, > > > On 21/04/2009, at 1:08 PM, Amos Jeffries wrote: > >> Sorry I'm wandering in the vague area between access methods and >> routing >> directions here. What I mean is an aggregate of all that. >> >> At present we have: >> DIRECT via IP #1 >> DIRECT via IP #2 >> ... repeat for all possible IPs. >> PEER #1 >> PERR #2 >> REEP # ... 64 >> >> Doing each of those within a 1 minute timeout and 10x attempts per >> route >> causes unreasonably long delays and false-failures. A few hacks reduce >> this somewhat by dropping the timeout, doing one connect when >1 IPs >> found, and only trying one peer per request, using netdb to improve >> the >> peers chances of working, but still hitting the problem. > > -- > Mark Nottingham m...@yahoo-inc.com > > >