Re: [squid-users] hier_code acl and cache allow/deny

On Sat, Feb 15, 2014 at 1:46 PM, Amos Jeffries <squid3_at_treenet.co.nz> 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
Received on Sat Feb 15 2014 - 13:13:03 MST