httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <>
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 12:03:03 GMT
On Mon, October 30, 2006 12:57 pm, Nick Kew 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?


- the cache_body() hook is expected to swallow an entire brigade
completely and write it to cache completely before this brigade is written
to the network.

In the case of files, that means one brigade, containing one bucket,
containing one entire file. For a 4.7GB DVD ISO file, that means many
minutes before the response starts arriving at the client, which has timed
out at this point.

- apr_bucket_read() assumes that a bucket will only ever be read once.

In so doing, it may morph buckets into heap buckets while reading, when
buckets are too large to be read in one go. This behaviour is undocumented
(I plan to fix that).

If these heap buckets are not immediately deleted, they will last the
lifetime of a request. They are not deleted in mod_disk_cache because
later, we need to write these same buckets to the network. Out of memory

> (references to previous discussion will do, if applicable)

Previous discussion is just noise, it would be better if I explain again.

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

Sorry, but when Google buys YouTube for a Googol dollars, the argument
that nobody wants to serve large files makes no sense.

The existing mod_cache, regardless of configuration, and regardless of
cache disk size, can under no circumstances cache a file bigger than
available RAM.

This is well and truly broken.

> 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?

No - as Will Rowe pointed out, developing these ideas under a rock with no
oversight, and then suddenly producing a "finished work" does not benefit

The patches were posted to this dev list a long time ago, and nobody took
any time to review them. I see no reason why anybody is going to review
patches going in on some parallel dev branch either.


View raw message