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" <steve.ow...@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? > > > > > >
