On Sat, Feb 15, 2014 at 1:46 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 15/02/2014 10:35 a.m., Niki Gorchilov wrote: >> Hi all, >> >> I keep exploring the darkest corners of the Squid universe thus >> meeting unexpected creatures. :-) >> >> Today's discovery is hier_code ACL. >> >> I stumbled upon it while looking for a way to prevent SMP workers from >> swapping duplicate objects they got from the shared memory cache. >> >> On second thought, hier_code could also help me prevent swapping >> objects fetched from cache peers, making my peername ACL redundant. >> >> Oh, great! 2-in-1. Let's do it: >> >> ===[cut]=== >> # swap only objects fetched directly from source >> # objects fetched from cache peers or >> # shared memory shall not be cached >> acl direct hier_code HIER_DIRECT >> acl direct hier_code CLOSEST_DIRECT >> acl direct hier_code SOURCE_FASTEST >> acl direct hier_code PINNED >> acl direct hier_code ORIGINAL_DST >> cache allow direct >> cache deny all >> ===[cut]=== >> >> Unfortunately, the above config prevented ANY objects from being >> cached, like the hier_code wasn't available at the time the swap >> decision is taken. >> >> Am I doing it wrong? Is it possible to use hier_code acl against cache >> deny/allow? > > 1) Lets start with "swap" and "swapping". What exactly do you mean by > those words? I mean storing object to disk. I.e. SWAPOUT record in store.log > Your usage does not seem to mean the same as storing data on disk, and > exchanging objects in a two-way transaction does not match HTTP. I'm trying to avoid the following scenario (excerpt from store.log): 1392406208.398 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET http://www.gnu.org/graphics/t-desktop-4-small.jpg 1392406242.459 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET http://www.gnu.org/graphics/t-desktop-4-small.jpg First request was served by kid1. It fetched the object by HIER_DIRECT, memory cached it, and stored it to it's storage (say /S1). Seconds later, the same request arrives to kid2. It retrieves the object from shared memory (hierarchy code NONE), then swaps it out to it's own storage (say /S2). The question is how to prevent kid2 from saving the duplicate object? Is there any mechanism other then switching memory_cache_shared off? > 2) "cache" access control determines whether object are stored by the > current Squid in any of the cache areas. It is checked right after > receiving the request, so things like how it will be fetched are > completely unkown. OK. Clear. > 3) hier_code is available from the point a successful server connection > has been made. Up until that point it is "NONE". > It should work in the tcp_outgoing_* access controls which are done on > a per-destination basis on each hierarchy path. But I am not sure of that. Got it. Niki