httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c
Date Mon, 30 Oct 2006 10:57:59 GMT
On Mon, 30 Oct 2006 01:53:18 +0200
Graham Leggett <> wrote:

> The current expectation that it be possible to separate completely
> the storing of the cached response and the delivery of the content is
> broken.

Why is that?
(references to previous discussion will do, if applicable)

> We have a real world case where the cache is expected to process a
> many MB or many GB file completely, before sending that same response
> to the network. This is too slow, and takes up too much RAM,
> resulting in a broken response to the client.

That suggests broken or implementation and/or inappropriate usage.
It says nothing about expectation.

> On wednesday night I wrote a patch that solved the large file
> problem, while maintaining the current separation between
> write-to-cache and write-to-network as you assert. This mod_cache
> code broke up the brigade into bite sized chunks inside mod_cache
> before passing it to write-to-cache, then write-to-network, and so on.
> Joe vetoed the patch, saying that it duplicated the natural behaviour
> of apr_bucket_read().
> The wednesday night patch was reverted, and thursday night was spent 
> instead changing the cache_body() signature to make its own better 
> judgement on how to handle cached files.
> Now you veto this next patch, saying it breaks the abstraction.

All of which says this work is in a state of flux.

> I agree with you that a design needs to be found on list first, as I 
> have wasted enough time going round in circles coming up with
> solution after solution nobody is happy with.
> Do we put this to a vote?

There are quite a lot of contributors, and there may be competing
designs.  That sounds like the kind of situation where a single
/trunk/ and a single cache framework instance is hopelessly
inadequate. If necessary, let it fork, demo your ideas on a 
branch, then present that for discussion.

Isn't that approximately what Paul suggested some time back?

Nick Kew

View raw message