Re: More patches for squid2-HEAD
On 2-HEAD. On 14/05/2009, at 6:36 PM, Mark Nottingham wrote: On 23/04/2009, at 10:38 AM, Mark Nottingham wrote: http://www.squid-cache.org/bugs/show_bug.cgi?id=2643 http://www.squid-cache.org/bugs/show_bug.cgi?id=2631 These are the last two remaining. There's been some discussion on them, but I believe the issues have been resolved in the most recent patches attached to them; if I don't hear otherwise soon, I'll go ahead and apply to 2-HEAD. Cheers, -- Mark Nottingham m...@yahoo-inc.com -- Mark Nottingham m...@yahoo-inc.com
Re: More patches for squid2-HEAD
On 23/04/2009, at 10:38 AM, Mark Nottingham wrote: http://www.squid-cache.org/bugs/show_bug.cgi?id=2643 http://www.squid-cache.org/bugs/show_bug.cgi?id=2631 These are the last two remaining. There's been some discussion on them, but I believe the issues have been resolved in the most recent patches attached to them; if I don't hear otherwise soon, I'll go ahead and apply to 2-HEAD. Cheers, -- Mark Nottingham m...@yahoo-inc.com
Re: More patches for squid2-HEAD
tor 2009-04-23 klockan 13:22 +1000 skrev Mark Nottingham: > OK. Henrik? > > FWIW, I think this is the right way to do it -- a flag saying that > monitoring should be direct is backwards-compatible, easy for users to > understand, and addresses the use case. Almost. The flag should make the request go via normal forwarding selection, not forced direct, or to the specific peer (as today).. Regards Henrik
Re: More patches for squid2-HEAD
On 23/04/2009, at 2:11 PM, Amos Jeffries wrote:
On 21/04/2009, at 10:44 AM, Mark Nottingham wrote:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
Amos, any thoughts about the revised patch ("monitor-direct")?
I still don't agree that this is anything close to the Right Way to
do it.
Easy, yes, but thats all. Please hold off until Henrik can get a
good look
at it and voice his opinion.
OK. Henrik?
FWIW, I think this is the right way to do it -- a flag saying that
monitoring should be direct is backwards-compatible, easy for users to
understand, and addresses the use case.
http://www.squid-cache.org/bugs/show_bug.cgi?id=2631
Amos, does this make sense now?
http://www.squid-cache.org/bugs/show_bug.cgi?id=2632
I think we cleared up confusion in discussion; applying unless I hear
otherwise.
Well, Henrik may have other opinions since he has to manage it. But
I'm no
longer objecting to it as a temporary measure.
Assuming that this applies to both. H?
--
Mark Nottingham m...@yahoo-inc.com
Re: More patches for squid2-HEAD
>
> On 21/04/2009, at 10:44 AM, Mark Nottingham wrote:
>
>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
>
> Amos, any thoughts about the revised patch ("monitor-direct")?
>
I still don't agree that this is anything close to the Right Way to do it.
Easy, yes, but thats all. Please hold off until Henrik can get a good look
at it and voice his opinion.
>
http://www.squid-cache.org/bugs/show_bug.cgi?id=2631
>
> Amos, does this make sense now?
>
>
http://www.squid-cache.org/bugs/show_bug.cgi?id=2632
>
> I think we cleared up confusion in discussion; applying unless I hear
> otherwise.
>
Well, Henrik may have other opinions since he has to manage it. But I'm no
longer objecting to it as a temporary measure.
Amos
Re: More patches for squid2-HEAD
On 21/04/2009, at 10:44 AM, Mark Nottingham wrote:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2642
Seems uncontroversial, applying.
http://www.squid-cache.org/bugs/show_bug.cgi?id=2643
Amos, any thoughts about the revised patch ("monitor-direct")?
http://www.squid-cache.org/bugs/show_bug.cgi?id=2631
Amos, does this make sense now?
http://www.squid-cache.org/bugs/show_bug.cgi?id=2632
I think we cleared up confusion in discussion; applying unless I hear
otherwise.
http://www.squid-cache.org/bugs/show_bug.cgi?id=2515
Patch seems to work; applying.
--
Mark Nottingham m...@yahoo-inc.com
Re: More patches for squid2-HEAD
> 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 > > >
Re: More patches for squid2-HEAD
On 21/04/2009, at 1:24 PM, Amos Jeffries wrote: Responses inline, and a couple more: http://www.squid-cache.org/bugs/show_bug.cgi?id=2642 I can't tell from the patch which one is being remove. +1 if its the one directly in mainReconfigure() Yep. peerMonitorInit() should probably check for duplicate calls somehow too. But this is good for a quick fix. http://www.squid-cache.org/bugs/show_bug.cgi?id=2643 -1 right now. see bug report. Responded there. Cheers, -- Mark Nottingham m...@yahoo-inc.com
Re: More patches for squid2-HEAD
>> >> Responses inline, and a couple more: >> >> http://www.squid-cache.org/bugs/show_bug.cgi?id=2642 I can't tell from the patch which one is being remove. +1 if its the one directly in mainReconfigure() peerMonitorInit() should probably check for duplicate calls somehow too. But this is good for a quick fix. >> http://www.squid-cache.org/bugs/show_bug.cgi?id=2643 -1 right now. see bug report. Amos
Re: More patches for squid2-HEAD
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. 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
Re: More patches for squid2-HEAD
> > Responses inline, and a couple more: > > http://www.squid-cache.org/bugs/show_bug.cgi?id=2642 > http://www.squid-cache.org/bugs/show_bug.cgi?id=2643 > > > On 20/04/2009, at 4:46 PM, Amos Jeffries wrote: > >> Mark Nottingham wrote: >>> Unless I hear otherwise, I'm going to apply the patches attached to >>> the following bugs: >>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2631 >> >> response in bugzilla. > > Likewise. > > >>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2632 >> >> IMO, this should be number of times squid tries _each_ available >> forwarding method before giving up on it. With a default of >> something lower, 1 or 2 may be reasonable in most of todays internet. >> >> +1 on the configurable idea though. > > Sorry, could you explain what you mean by each method? Is it direct > vs. peer? 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. > > >> Definitely relevant to squid-3, if you commit this for 2 before it >> gets to 3, please just comment "commited to squid-2" and bump target >> milestone to 3.HEAD > > Ack. > > >>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2515 >> >> Looks good to me. Mind the formatting though. > > Yeah. Still can't get the proper version of indent running on OSX, so > I have to shove it to another box to indent before submission... Manual works easier and sometimes faster for small patches like this. :) > >> Is it relevant to squid-3 parser? > > Don't think so; StringToInt64 doesn't look at errno. > Great. Was wondering why I could not find it. Amos
Re: More patches for squid2-HEAD
Responses inline, and a couple more: http://www.squid-cache.org/bugs/show_bug.cgi?id=2642 http://www.squid-cache.org/bugs/show_bug.cgi?id=2643 On 20/04/2009, at 4:46 PM, Amos Jeffries wrote: Mark Nottingham wrote: Unless I hear otherwise, I'm going to apply the patches attached to the following bugs: http://www.squid-cache.org/bugs/show_bug.cgi?id=2631 response in bugzilla. Likewise. http://www.squid-cache.org/bugs/show_bug.cgi?id=2632 IMO, this should be number of times squid tries _each_ available forwarding method before giving up on it. With a default of something lower, 1 or 2 may be reasonable in most of todays internet. +1 on the configurable idea though. Sorry, could you explain what you mean by each method? Is it direct vs. peer? Definitely relevant to squid-3, if you commit this for 2 before it gets to 3, please just comment "commited to squid-2" and bump target milestone to 3.HEAD Ack. http://www.squid-cache.org/bugs/show_bug.cgi?id=2515 Looks good to me. Mind the formatting though. Yeah. Still can't get the proper version of indent running on OSX, so I have to shove it to another box to indent before submission... Is it relevant to squid-3 parser? Don't think so; StringToInt64 doesn't look at errno. -- Mark Nottingham m...@yahoo-inc.com
Re: More patches for squid2-HEAD
Responses inline, and a couple more: http://www.squid-cache.org/bugs/show_bug.cgi?id=2642 http://www.squid-cache.org/bugs/show_bug.cgi?id=2643 On 20/04/2009, at 4:46 PM, Amos Jeffries wrote: Mark Nottingham wrote: Unless I hear otherwise, I'm going to apply the patches attached to the following bugs: http://www.squid-cache.org/bugs/show_bug.cgi?id=2631 response in bugzilla. Likewise. http://www.squid-cache.org/bugs/show_bug.cgi?id=2632 IMO, this should be number of times squid tries _each_ available forwarding method before giving up on it. With a default of something lower, 1 or 2 may be reasonable in most of todays internet. +1 on the configurable idea though. Sorry, could you explain what you mean by each method? Is it direct vs. peer? Definitely relevant to squid-3, if you commit this for 2 before it gets to 3, please just comment "commited to squid-2" and bump target milestone to 3.HEAD Ack. http://www.squid-cache.org/bugs/show_bug.cgi?id=2515 Looks good to me. Mind the formatting though. Yeah. Still can't get the proper version of indent running on OSX, so I have to shove it to another box to indent before submission... Is it relevant to squid-3 parser? Don't think so; StringToInt64 doesn't look at errno. -- Mark Nottingham m...@yahoo-inc.com
Re: More patches for squid2-HEAD
Mark Nottingham wrote: Unless I hear otherwise, I'm going to apply the patches attached to the following bugs: http://www.squid-cache.org/bugs/show_bug.cgi?id=2631 response in bugzilla. http://www.squid-cache.org/bugs/show_bug.cgi?id=2632 IMO, this should be number of times squid tries _each_ available forwarding method before giving up on it. With a default of something lower, 1 or 2 may be reasonable in most of todays internet. +1 on the configurable idea though. Definitely relevant to squid-3, if you commit this for 2 before it gets to 3, please just comment "commited to squid-2" and bump target milestone to 3.HEAD http://www.squid-cache.org/bugs/show_bug.cgi?id=2515 Looks good to me. Mind the formatting though. Is it relevant to squid-3 parser? Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14 Current Beta Squid 3.1.0.7
More patches for squid2-HEAD
Unless I hear otherwise, I'm going to apply the patches attached to the following bugs: http://www.squid-cache.org/bugs/show_bug.cgi?id=2631 http://www.squid-cache.org/bugs/show_bug.cgi?id=2632 http://www.squid-cache.org/bugs/show_bug.cgi?id=2515 -- Mark Nottingham m...@yahoo-inc.com
