Re: [squid-users] Why are cache_peer_access acls called 4 times in a row?
Thanks. So if the web server did not understand what domain is served the first call, why would it understand in the next calls? It eventually returns the right page. The web server log shows only one call. The web server returns the right page when you call this URL from wget or a browser with an IP number and without a domain (and eventually squid gets the right page too), it has a default context. By the way if I take out the cache_peer and cache_peer_access and do always direct instead, everything seems to work properly. E - Original Message - From: Amos Jeffries [EMAIL PROTECTED] To: Elli Albek [EMAIL PROTECTED] Cc: squid-users@squid-cache.org Sent: Sat, 18 Oct 2008 21:25:32 -0700 (PDT) Subject: Re: [squid-users] Why are cache_peer_access acls called 4 times in a row? Elli Albek wrote: Hi, I have a simple setup for testing accelerator: http_port 127.0.0.4:80 accel defaultsite=1.2.3.4:80 cache_peer 1.2.3.4 parent 80 0 no-query originserver name=parent_sl acl my_acl urlpath_regex ^/rev/ acl port80 port 80 http_access deny !port80 http_access allow port80 cache_peer_access parent_sl allow my_acl There are no other acls and configuration except from what is in the base squid.conf.default. When I request a URL from squid I can see in the trace that the acl my_acl is executed 4 times consecutively. This acl is only used in cache_peer_access parent_sl once and in no other place. The following trace shows up in the log 4 times one after the other, and in all of them it is a success (returning 1): aclCheckFast: list: 003CA058 aclMatchAclList: checking my_acl aclMatchAcl: checking 'acl my_acl urlpath_regex ^/rev/' aclMatchRegex: checking '/rev/288/scripts/v2/lib/util.js' aclMatchRegex: looking for '^/rev/' aclMatchRegex: match '^/rev/' found in '/rev/288/scripts/v2/lib/util.js' aclMatchAclList: returning 1 aclCheckFast: list: 003CA058 What is the reason for that? Other acls in the file are invoked only once (seen in the trace), but acls on cache_peer_access are always called 3 or 4 times. 4 connection attempts were tried? ie request failed because the web server doesn't understand what domain is supposed to be served when asked for http://127.0.0.4/rev/fubar Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [squid-users] Why are cache_peer_access acls called 4 times in a row?
On sön, 2008-10-19 at 17:25 +1300, Amos Jeffries wrote: The following trace shows up in the log 4 times one after the other, and in all of them it is a success (returning 1): What is the reason for that? Other acls in the file are invoked only once (seen in the trace), but acls on cache_peer_access are always called 3 or 4 times. 4 connection attempts were tried? No. peer acls is evaluated during peering selection, not during re-forwarding. More likely it's because the peer was selected by 4 different algorithms. It's an accelerator where going direct is not allowed so Squid tries really hard to find all possible paths to forward the request. Regards Henrik
Re: [squid-users] Why are cache_peer_access acls called 4 times in a row?
Thanks. It makes sense since setting always direct to this acl evaluates the acl once (and also once on the always direct rule, but this is expected). The four acl evaluations return success, so is it possible to configure squid to stop at the first success or just evaluate one algorithm? E No. peer acls is evaluated during peering selection, not during re-forwarding. More likely it's because the peer was selected by 4 different algorithms. It's an accelerator where going direct is not allowed so Squid tries really hard to find all possible paths to forward the request. Regards Henrik
Re: [squid-users] Why are cache_peer_access acls called 4 times in a row?
On sön, 2008-10-19 at 17:12 -0700, Elli Albek wrote: It makes sense since setting always direct to this acl evaluates the acl once (and also once on the always direct rule, but this is expected). The four acl evaluations return success, so is it possible to configure squid to stop at the first success or just evaluate one algorithm? Not without changing the code. See the peerSelectFoo() function. Regards Henrij signature.asc Description: This is a digitally signed message part
[squid-users] Why are cache_peer_access acls called 4 times in a row?
Hi, I have a simple setup for testing accelerator: http_port 127.0.0.4:80 accel defaultsite=1.2.3.4:80 cache_peer 1.2.3.4 parent 80 0 no-query originserver name=parent_sl acl my_acl urlpath_regex ^/rev/ acl port80 port 80 http_access deny !port80 http_access allow port80 cache_peer_access parent_sl allow my_acl There are no other acls and configuration except from what is in the base squid.conf.default. When I request a URL from squid I can see in the trace that the acl my_acl is executed 4 times consecutively. This acl is only used in cache_peer_access parent_sl once and in no other place. The following trace shows up in the log 4 times one after the other, and in all of them it is a success (returning 1): aclCheckFast: list: 003CA058 aclMatchAclList: checking my_acl aclMatchAcl: checking 'acl my_acl urlpath_regex ^/rev/' aclMatchRegex: checking '/rev/288/scripts/v2/lib/util.js' aclMatchRegex: looking for '^/rev/' aclMatchRegex: match '^/rev/' found in '/rev/288/scripts/v2/lib/util.js' aclMatchAclList: returning 1 aclCheckFast: list: 003CA058 What is the reason for that? Other acls in the file are invoked only once (seen in the trace), but acls on cache_peer_access are always called 3 or 4 times. Thanks Elli
Re: [squid-users] Why are cache_peer_access acls called 4 times in a row?
Elli Albek wrote: Hi, I have a simple setup for testing accelerator: http_port 127.0.0.4:80 accel defaultsite=1.2.3.4:80 cache_peer 1.2.3.4 parent 80 0 no-query originserver name=parent_sl acl my_acl urlpath_regex ^/rev/ acl port80 port 80 http_access deny !port80 http_access allow port80 cache_peer_access parent_sl allow my_acl There are no other acls and configuration except from what is in the base squid.conf.default. When I request a URL from squid I can see in the trace that the acl my_acl is executed 4 times consecutively. This acl is only used in cache_peer_access parent_sl once and in no other place. The following trace shows up in the log 4 times one after the other, and in all of them it is a success (returning 1): aclCheckFast: list: 003CA058 aclMatchAclList: checking my_acl aclMatchAcl: checking 'acl my_acl urlpath_regex ^/rev/' aclMatchRegex: checking '/rev/288/scripts/v2/lib/util.js' aclMatchRegex: looking for '^/rev/' aclMatchRegex: match '^/rev/' found in '/rev/288/scripts/v2/lib/util.js' aclMatchAclList: returning 1 aclCheckFast: list: 003CA058 What is the reason for that? Other acls in the file are invoked only once (seen in the trace), but acls on cache_peer_access are always called 3 or 4 times. 4 connection attempts were tried? ie request failed because the web server doesn't understand what domain is supposed to be served when asked for http://127.0.0.4/rev/fubar Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
