Re: Poll: Which bzr versions are you using?
2010/5/20 Henrik Nordström : > For repository maintenance reasons I need to know which minimum bzr > version all who work with the Squid repository need to be able to use. > And I mean all, including those who do not have direct commit access. > > I.e the output of "bzr --version | head -1" on the oldest platform you > need or want to access the main bzr repository from. Bazaar (bzr) 2.0.2 -- /kinkie
Re: [MERGE] Squid Patch (revision 10487)
tor 2010-05-20 klockan 12:00 +1000 skrev Mark Nottingham: > H, is setting the default to on a bad thing? Probably not, as the code takes care of allow-miss. related to this the behavior when the sibling rejects the request need to be verified. This change will make only-if-cached rejections in sibling relations much more frequent than today. Regards Henrik
Re: Poll: Which bzr versions are you using?
in general No; the .bzr.log in a users homedir will contain some info, possibly the client version: the server does receive that, I think. Over HTTP bzr is just another client - the user agent field includes the bzr version, I think, if you were to look in apache logs. -Rob
Re: [MERGE] Squid Patch (revision 10487)
Minor suggestions for the documentation: +NAME: access_sibling_when_stale +COMMENT: on|off +TYPE: onoff +DEFAULT: off +LOC: Config.onoff.access_sibling_for_stale_resource +DOC_START + By default, Squid will not contact siblings when it has + a stale cached response available. If on, siblings + that do not have the 'allow-miss' cache_peer option will + be queried even when there is a stale cached response. +DOC_END H, is setting the default to on a bad thing? I'll produce the patch for 2.HEAD. Regards, -- Mark Nottingham m...@yahoo-inc.com
Re: Poll: Which bzr versions are you using?
On Thu, 20 May 2010 12:31:50 +1200, Robert Collins wrote: > 2.2 :> Robert, is there some access log or such recorded by bzr about who or when a connection was made to which branch and with what version? Amos
RE: [MERGE] Squid Patch (revision 10487)
On Wed, 19 May 2010 10:03:11 -0500, wrote: > Not sure what went wrong, but since changes in each of the 3 files are > minimal I included differences as attachments (new version for each file is > on top, old version is on bottom): > > neighbor.cc_diff.jpg - shows changes in neighbor.cc file in the > peerAllowedToUse method. > structs.h_diff.jpg - shows a single variable that has been added to onoff > struct in the structs.h file. > cf.data.pre_diff.jpg - shows info that has been added for a new > access_sibling_for_stale_resource directive in cf.data.pre. > Okay. Thats more readable at least. +1 provided this has some testing behind it. > Let me know what you think. I can try couple different things with Bazaar > to generate correct patch file if needed. Not sure beyond the ones I use daily ...to see unsaved changes: bzr diff ...to see changes in a branch back to its parent (ie trunk): bzr diff -rsubmit: I suspect there might be something like whitespacing or \n \r differences in your OS or editor from the stored type the rest of us use. Are you using Eclipse or Emacs for an editor? they are known to change end-of-line characters by default sometimes. Amos > > Thanks in advance, > Senad > > -Original Message- > From: Amos Jeffries [mailto:squ...@treenet.co.nz] > Sent: Tuesday, May 18, 2010 6:55 PM > To: squid-dev@squid-cache.org > Subject: Re: [MERGE] Squid Patch (revision 10487) > > On Tue, 18 May 2010 16:25:31 -0500, > wrote: >> Attached file is generated patch for the issue where squid does not >> contact its siblings for the stale resources. New directive has been >> added to make this behavior optional. >> >> Let me know if any issues. > > Something has gone wrong in the patch creation or formatting process. Each > file that you have altered even slightly is removed completely and replaced > with a whole new version. This makes it extremely hard to tell what changes > you have made. > > Amos
Re: Poll: Which bzr versions are you using?
2.2 :>
Poll: Which bzr versions are you using?
For repository maintenance reasons I need to know which minimum bzr version all who work with the Squid repository need to be able to use. And I mean all, including those who do not have direct commit access. I.e the output of "bzr --version | head -1" on the oldest platform you need or want to access the main bzr repository from. Regards Henrik
Re: [MERGE] Squid Patch (revision 10487)
tis 2010-05-18 klockan 16:25 -0500 skrev senad.ci...@thomsonreuters.com: > Attached file is generated patch for the issue where squid does not > contact its siblings for the stale resources. New directive has been > added to make this behavior optional. Corrected patch attached showing only your changes. Regards Henrik === modified file 'src/cf.data.pre' --- src/cf.data.pre 2010-05-14 05:37:19 + +++ src/cf.data.pre 2010-05-19 18:29:28 + @@ -6941,4 +6941,15 @@ Whether to lookup the EUI or MAC address of a connected client. DOC_END +NAME: access_sibling_for_stale_resource +COMMENT: on|off +TYPE: onoff +DEFAULT: off +LOC: Config.onoff.access_sibling_for_stale_resource +DOC_START + By default, Squid will not contact siblings for cached but + expired (stale) resources. If this directive is set to on, + that behavior will change unless sibling has allow-miss option set. +DOC_END + EOF === modified file 'src/neighbors.cc' --- src/neighbors.cc 2010-05-02 19:32:42 + +++ src/neighbors.cc 2010-05-19 18:29:28 + @@ -156,13 +156,19 @@ if (request->flags.nocache) return 0; -if (request->flags.refresh) +/*Ignore refresh flag if access_sibling_for_stale_resource flag is on unless allow_miss is enabled for this peer + (needed to avoid forwarding loops).*/ +if (request->flags.refresh && !Config.onoff.access_sibling_for_stale_resource || +request->flags.refresh && p->options.allow_miss) return 0; if (request->flags.loopdetect) return 0; -if (request->flags.need_validation) +/*Ignore need_validation flag if access_sibling_for_stale_resource flag is on unless allow_miss is enabled for this peer + (needed to avoid forwarding loops).*/ +if (request->flags.need_validation && !Config.onoff.access_sibling_for_stale_resource || +request->flags.need_validation && p->options.allow_miss) return 0; } === modified file 'src/structs.h' --- src/structs.h 2010-04-17 02:29:04 + +++ src/structs.h 2010-05-19 18:29:28 + @@ -437,6 +437,7 @@ int WIN32_IpAddrChangeMonitor; int memory_cache_first; int memory_cache_disk; +int access_sibling_for_stale_resource; } onoff; int forward_max_tries;
RE: [MERGE] Squid Patch (revision 10487)
ons 2010-05-19 klockan 10:03 -0500 skrev senad.ci...@thomsonreuters.com: > Not sure what went wrong, but since changes in each of the 3 files are > minimal I included differences as attachments (new version for each > file is on top, old version is on bottom): Probably got converted from UNIX to DOS line endings. Regards Henrik
[DRAFT][MERGE] Cleanup comm outgoing connections in trunk
Henrik Nordström wrote:
tis 2010-05-18 klockan 23:34 + skrev Amos Jeffries:
I've discovered the VC connections in DNS will need a re-working to handle
the new TCP connection setup handling. I've left that for now since it
appears that you are working on redesigning that area anyway. The new setup
routines will play VERY nicely with persistent TCP links to the
nameservers.
I have not started on the DNS rewrite yet.
I took some extra time last night and broke the back of the selection and
forwarding rewrite. I'm now down to the fine detail build errors. When
those are done I'll push the branch to LP for you to do the DNS fixes on
top of.
Ok.
Pushed to launchpad: lp:~yadi/squid/cleanup-comm
This builds, but has not yet been run tested.
What has changed:
ConnectionDetails objects have been renamed Comm::Connection and been
extended to hold the FD and Squids' socket flags.
Peer selection has been extended to do DNS lookups on the peers chosen
for forwarding to and produce a vector<> of possible connection
endpoints (squid local IP via tcp_outgoing_address or tproxy) and remote
server.
Various connection openers have been converted to use the new
ConnectStateData API and CommCalls (function based so far).
ConnectStateData has been moved into src/comm/ (not yet namespaced) and
had all its DNS lookup operations dropped. To be replaced by a looping
process of attempting to open a socket and join a link as described by
some Comm::Connection or vector<> of same.
ConnectStateData::connect() will go away and do some async work. Will
come back at some point by calling the handler with COMM_OK,
COMM_ERR_CONNECT, COMM_TIMEOUT and ptrs to the Comm::Connection or
vector (whichever were passed in).
On COMM_OK the Comm::Connection pointer or the first entry of the
vector will be an open conn which we can now use.
On COMM_ERR_CONNECT the vector will be empty (all tried and
discarded), the single ptr will be closed if not NULL.
On COMM_TIMEOUT their content is as per COMM_ERR_CONNECT but the
vector may have untried paths still present but closed.
FD opening, FD problems, connection errors, timeouts, early remote
TCP_RST or NACK closure during the setup are all now wrapped out of
sight inside ConnectStateData.
The main-level component may set FD handlers as needed for read/write
and closure of the link in their connection-done handler where the FD
first becomes visible to them.
Besides the testing there is some work to:
* make it obey squid.conf limits on retries and paths looked up.
* make DNS TCP links ('VC') work again.
* make the CommCalls proper AsynCalls and not function handler based.
* make Comm::Connection ref-counted so we can have them stored
in the peer details and further reduce the DNS steps.
* make ICAP do DNS lookups to set its server Comm::Connection properly.
For now it's stuck with the gethostbyname() blocking lookup.
Future work once this is stable is to:
a) push the IDENT, NAT, EUI and TLS operations down into the Comm
layer with simple flags for other layers to turn them on/off as desired.
b) make the general code pass Comm::Connection around so everything
like ACLs can access the client and server conn when they need to.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.3
Re: [RFC] squid purge tool
ons 2010-05-19 klockan 22:46 +1200 skrev Amos Jeffries: > Looks as compatibile as we can get. Agreed. Regards Henrik
Re: [RFC] squid purge tool
Henrik Nordström wrote: tis 2010-05-18 klockan 23:42 + skrev Amos Jeffries: I have the impression the purge tool is probably worth bundling with Squid alongside squidclient and cachemgr.cgi in the tools/ section. Before the license was incompatible. Haven't looked if the license changed at the end of the project. The only lisence I can find associated with the code that would be merged is this open-ended disclaimer: // Permission to use, copy, modify, distribute, and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that (i) the above copyright notices and this permission // notice appear in all copies of the software and related documentation, // and (ii) the names of the Lehrgebiet Rechnernetze und Verteilte // Systeme and the University of Hannover may not be used in any // advertising or publicity relating to the software without the // specific, prior written permission of Lehrgebiet Rechnernetze und // Verteilte Systeme and the University of Hannover. Looks as compatibile as we can get. Before I go ahead and try to find the tool developer what is the consensus on bundling and maintaining it further ourselves? The purge tool was developed as part of the dfncache project I think. The current maintainer have not touched the code at all. Regards Henrik Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.3
Re: [RFC] squid purge tool
tis 2010-05-18 klockan 23:42 + skrev Amos Jeffries: > I have the impression the purge tool is probably worth bundling with Squid > alongside squidclient and cachemgr.cgi in the tools/ section. Before the license was incompatible. Haven't looked if the license changed at the end of the project. > Before I go ahead and try to find the tool developer what is the consensus > on bundling and maintaining it further ourselves? The purge tool was developed as part of the dfncache project I think. The current maintainer have not touched the code at all. Regards Henrik
Re: [MERGE] [3.1] Clean up commReset use in combination with tproxy or tcp_outgoing_address
tis 2010-05-18 klockan 23:34 + skrev Amos Jeffries: > I've discovered the VC connections in DNS will need a re-working to handle > the new TCP connection setup handling. I've left that for now since it > appears that you are working on redesigning that area anyway. The new setup > routines will play VERY nicely with persistent TCP links to the > nameservers. I have not started on the DNS rewrite yet. > I took some extra time last night and broke the back of the selection and > forwarding rewrite. I'm now down to the fine detail build errors. When > those are done I'll push the branch to LP for you to do the DNS fixes on > top of. Ok. Regards Henrik
