Monday, September 10, 2012, 5:14:40 PM, you wrote: > Can we also consider the other way: make the request to the origin server > with a larger range so that we may 'join' two disjoint parts of the data? > (try to avoid having many empty chunks in between filled chunks)
We can consider it but I think it won't work. It would require, among other things, cleverness in changing the outgoing request *and* tweaking the response so that the client gets the originally requested range. Unlikely to be worth it - better to do something in the nature of the other bug you mentioned where, in a plugin, completely synthetic range request are generated to fill gaps. > The solution with the chunk validity bitmap has the advantage that it works > fine without throwing away cached data. > Does throwing away parts of a cached object while updating the cache for > the same object raise any synchronization issues? No, because you don't really throw away the data, you simply change the valid span values in the fragment. Reading and writing those have to be synchronized for other reasons so it's no additional cost. Which is better may well depend on our anticipated access pattern. It's easy to think of a plausible pattern where a client "rolls through" an object via range requests (a very common pattern in practice) and each range request spans chunks without every covering a chunk so you don't actually store anything from the entire set of requests, even though ATS saw the entire object. The span scheme, OTOH, would end up capturing the entire object.
