Cache Propagation Delay

["Owens, Steve" <St...@disney.com>]

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?

FW: Cache Propagation Delay

["Owens, Steve" <St...@disney.com>]

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?
>
>
>
>
>
>