You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Owens, Steve" <St...@disney.com> on 2012/10/25 19:00:15 UTC

FW: Cache Propagation Delay

Forwarding to the DEV group due to the nature of the question.

Put Succinctly:

The question I have is does anybody know what the upper bound is for
propagation delay on cache updates as a consequence of a PUT throughout
the cluster such that all nodes are consistent with regard to the updated
item?


See below for more information.


On 10/23/12 3:01 PM, "Owens, Steve" <St...@disney.com> wrote:

>Recently we ran in to issues with regard to cache propagation. The use
>case is as follows:
>
>1. Client does a get on a resource, and the server returns the resource
>and an Etag
>2. Client modifies the resource and does a PUT with an If-Match header.
>3. Repeat 1 and 2 several times
>
>Sometimes 2 succeeds, sometimes 2 fails with the origin service returning
>a 415 error (as per the HTTP spec).
>
>The reason for this is that when you do a PUT on a resource the ATS cache
>will purge any item under that URL.  BUT, it takes time to propagate that
>change throughout the cluster.
>
>We have done gets against the cluster for an updated resource and seen
>stale data returned as much as 10 seconds after the PUT was completed.
>
>The question I have is does anybody know what the upper bound is for
>propagation delay on cache updates as a consequence of a PUT throughout
>the cluster such that all nodes are consistent with regard to the updated
>item?
>
>
>
>
>
>