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 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
On 21/04/2009, at 10:44 AM, Mark Nottingham wrote: snip 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 23/04/2009, at 2:11 PM, Amos Jeffries wrote: On 21/04/2009, at 10:44 AM, Mark Nottingham wrote: snip 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
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
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
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
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 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
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
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
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
