Graham Leggett wrote:
To be HTTP compliant, and to solve thundering herd, we need the following from a cache:
This seems more like a wish list. I just want to separate out the cache and protocol stuff.
- The ability to amend a subkey (the headers) on an entry that is already cached.
mod_http_cache should handle. to new mod_cache, it's just another key/value.
- The ability to invalidate a particular cached variant (ie headers + data) in one atomic step, without affecting threads that hold that cached entry open at the time.
mod_http_cache should handle. Keep a list of variants cached - this should use a provider interface as well. mod_cache would handle whatever locking, ref counting, etc, needs to be done, if any.
- The ability to read from a cached object that is still being written to.
Nice to have. out of scope for what I am proposing. new mod_cache should be the place to implement this if underlying provider supports it.
- A guarantee that the result of a broken write (segfault, timeout, connection reset by peer, whatever) will not result in a broken cached entry (ie that the cached entry will eventually be invalidated, and all threads trying to read from it will eventually get an error).
agreed. new mod_cache should handle this.
Certainly separate the protocol from the physical cache, just make sure the physical cache delivers the shopping list above :)
Most seem like protocol specific stuff. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
