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?






Reply via email to