The summary says it - figure out the code paths involved with PURGE.
There's three calls to clientPurgeRequest():
* one in clientCacheHit() after the store url and vary logic checks;
* one in clientProcessRequest();
* one in clientProcessMiss().
I think the multiple points for handling PURGE is because of the object
processing pipeline with the lookups and processing handling occuring
asynchronously.
But I think it needs to be properly understood and untangled. Eg -
clientPurgeRequest() will do a cache lookup and swapin the metadata by
calling clientCacheHit(). clientCacheHit() will then do whatever other
checking is going on, then hopefully end up with the right object to feed
clientPurgeRequest() again. That will hopefully end up completing the purge
request. But there's a few places in the Vary handling where things fail or
aren't in the cache - then it ends up calling clientProcessMiss() which
will also call clientPurgeRequest() to complete the purge.
In any case, the logic is horrible, hairy, and deserves to be untangled as
part of a client-side processing pipeline tidyup.
Original issue reported on code.google.com by adrian.c...@gmail.com on 14 Feb 2010 at 7:17
Original issue reported on code.google.com by
adrian.c...@gmail.com
on 14 Feb 2010 at 7:17