Re: [RFC] cache architecture

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 25 Jan 2012 17:48:09 -0700

On 01/25/2012 05:32 PM, Amos Jeffries wrote:
> On 26.01.2012 08:26, Alex Rousskov wrote:
>> On 01/25/2012 01:20 AM, Henrik Nordström wrote:
>>> ons 2012-01-25 klockan 15:03 +1300 skrev Amos Jeffries:
>>>
>>>> We also need to enumerate how many of these cases are specifically
>>>> "MUST purge" versus "MUST update". The update case is a lot more
>>>> lenient
>>>> to sync issues than purges are.
>>>
>>> The case which matters here is that update actions done by a user should
>>> be immediately visible by the same user after accepted by the requested
>>> server.
>>>
>>> i.e. POST/PUT/DELETE etc need to invalidate any cached representation of
>>> the requested URL or Content-Location of response when same host.
>>
>> The above matches my expectations but I do not think it matches Amos'
>> point of view.
>
> I think I understand what you are trying to get at as the problem. But
> don't think we can claim it as a HTTP violation when all instances which
> received request (or knowledge of it) do purge properly.
>
> A cache/worker which is *completely* unaware of the POST/PUT/DELETE
> having ever happened cannot be held accountable for the result.

From client and server points of view, the "cache" is a single entity,
with a single address (i.e., "all workers together" or "any worker I
might end up talking to" if you wish). We can claim ignorance of those
points of view, but I think that would violate HTTP spirit if not the
letter.

We created workers as an internal performance optimization that has
nothing to do with HTTP. It is our responsibility to make sure that
optimization stays internal. If caches are not synchronized, the
optimization may negatively affect external HTTP agents.

Again, if HTTP has no text defining when two cooperating caches must be
in sync, then it would be difficult to decide which interpretation of
the HTTP spirit is "correct".

> We are wholly dependent on the server or client providing cache-controls
> that workaround the sync issues. So long as those controls and the purge
> are obeyed correctly *when received* I call it compliant.

IMO, we are responsible for delivering the right controls to all
cooperating caches. A client does not know we have many of them hiding
under a single Squid hood so it cannot make sure each of the caches
receives the necessary controls. The client has the right to treat all
workers as one because the client is talking to a single proxy address.

Cheers,

Alex.
Received on Thu Jan 26 2012 - 00:48:22 MST

This archive was generated by hypermail 2.2.0 : Thu Jan 26 2012 - 12:00:13 MST