On 8/6/12 8:04 AM, Ira Heffan wrote:
My company (TopCoder) on behalf of our client (Comcast) would like to make improvements to the range-handling of the ATS cache, basically addressing this issue: https://issues.apache.org/jira/browse/TS-974. For example, as we envision it, after our development effort, the cache will be able to serve requests out of partial objects and get more parts of a file to satisfy a range request.
This would be complicated, to say the least :). And, as the thread indicates, needs proper discussions on the mailing lists.
Part of the complication is that you can't just blindly cache any range request, for any substantially large object, there's a very large number of possible Range: requests (so, you could end up filling the entire cache for just a single object if not careful). So, some sort of minimium size requirements would have to be in place, e.g. chunk the object into <n>MB pieces. That gets particularly difficult to deal with now, since a request might cause the CacheSM to read a number of cache objects to satisfy the request.
We've had a discussion in the past of implementing a way to "background" fill the entire object into cache. I believe there's at least one bug filed for this, and there was also a lengthy discussion on the mailing list. Doing something like this would be substantially easier, but not as powerful as caching partial objects. While background filling an object, you might end up having to proxy some number of requests, until they can be served out of the partially written full-size object. You also only want to background fill objects that can be cached, and are likely to get more requests.
Our goal for this project is to have the code that we develop accepted back into the mainline project. We would therefore like to discuss our approach in advance with the appropriate ATS maintainers and, to the extent possible, receive feedback on our architecture/design plans as well as the developed code. Is this possible? If so, what is the best way to accomplish this? Our development team has subscribed to this list.
As Nick pointed out, the discussion definitely belongs here. I'd also encourage to start a Wiki page for collaboration (I don't think there is one, but double check before creating a new page).
Cheers, -- Leif
