> Your write up seems basically accurate to me. I would note again that > reading the earliest Doc of an alternate is an historical artifact of the > implementation and not at all a functional requirement. >
I see. I'm glad you cleared this out too. Initially I thought you planned to store the fragment table in this earliest Doc. I checked the trunk and saw it is stored in fact in the alternate entry itself (HTTPCacheAlt structure) The other half of the proposal is that, when servicing a range request that > has been forwarded to the origin server, we cache fill any complete chunks > that are returned and ignore any partial chunks. That's an elegant solution for keeping the chunk validity bitmap consistent! 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) > This is the point of having chunks, to make it much more likely that we > can capture data from range requests. We could do that with just fragments > but IMHO the granularity of that is too coarse. It might be interesting as > a first step to try it to validate the partial write logic. > > There is also the issue of how much compile time and/or run time control > should be provided over the graininess of the chunks. IMHO it would be > reasonable to support compile time control over a value N such that each > fragment consists of 2^N chunks. > I think this can be done. > The fragment tables changes are now on trunk, committed under the TS-1339 > bug ID. > Thanks for pointing that out. > > P.S. An alternative scheme would be to store for each fragment store a > valid span (two values, start/end) and then extend that if a range request > has an overlap. You could even, in the disjoint case, compute which span > had more data and keep that (e.g., effectively discard cached data if you > can replace it with a larger span in the fragment). > 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? > > Sunday, September 9, 2012, 5:37:29 PM, you wrote: > > > Thank you very much for the clarifications! > > > I think now I have a better view on the current cache structure and your > > proposal. > > > Who should also validate these changes before going to the next step > which > > I think would be the strategy of what and when to cache? > > > PS: is there a branch already available with your change to move the > > fragment table from the first Doc to the alternate entries? > >
