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

Reply via email to