httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Akins <brian.ak...@turner.com>
Subject Re: Possible new cache architecture
Date Tue, 02 May 2006 15:50:25 GMT
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

Mime
View raw message