httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF EITO <ruediger.pl...@vodafone.com>
Subject Re: cache: the store_body interface
Date Tue, 31 Oct 2006 13:29:21 GMT


> -----Ursprüngliche Nachricht-----
> Von: Joe Orton 
> Gesendet: Dienstag, 31. Oktober 2006 13:52
> An: dev@httpd.apache.org
> Betreff: Re: cache: the store_body interface
> 
> 
> On Tue, Oct 31, 2006 at 10:59:49AM +0000, Joe Orton wrote:
> > On Mon, Oct 30, 2006 at 02:56:24PM -0700, Justin Erenkrantz wrote:
> > > On 10/30/06, Nick Kew <nick@webthing.com> wrote:
> > > >What does that [#1] break?
> > > >
> > > >Seems an easy/low-level solution.  Does the provider return a
> > > >status value to say "I have/haven't passed this stuff down the
> > > >chain"?  It has the feel of something that pulls down the level
> > > >of abstraction: not sure what that loses.
> > > 
> > > With #1, you don't have any knowledge as to when the 
> filter died or
> > > how it died - was it the cache storage that died?  Or was it the
> > > client?  Who knows.  So, it makes recovering from storage failures
> > > very problematic or you put a set of 'hidden' constraints on the
> > > storage functions to try to encourage recovery - but I'd 
> rather make
> > > such things explicit.  -- justin
> > 
> > I very much sympathise with this argument.  But it does 
> mean that the 
> > storage provider cannot break any of the assumptions 
> mentioned in the 
> > other thread: it enforces the synchronous store-to-disk and 
> > write-to-client model.
> 
> I meant to also mention (sorry for all the mail): it prevents 
> mod_mem_cache's fd caching trick too, which relies on being 
> passed FILE 
> buckets.

That seems to be an important point to me. Although I never used
the fd caching of mod_mem_cache this would mean we actually would
have to dump this feature. This looks bad to me. Isn't this a showstopper
for implementing #3 as new interface?

Regards

Rüdiger


Mime
View raw message