httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fee <>
Subject RE: mod_cache: store_body() bites off more than it can chew
Date Mon, 13 Sep 2010 16:47:53 GMT
"Plüm, Rüdiger, VF-Group" wrote:

>> -----Original Message-----
>> From: Graham Leggett
>> Sent: Montag, 13. September 2010 16:35
>> To:
>> Subject: Re: mod_cache: store_body() bites off more than it can chew
>> On 13 Sep 2010, at 4:18 PM, Plüm, Rüdiger, VF-Group wrote:
>> > It is not a problem for mod_disk_cache as you say, but
>> > I guess he meant for 3rd party providers that could only deliver
>> > the cached responses via heap buckets.
>> The cache provider itself puts the bucket in the brigade, and
>> has the
>> power to put any bucket into the brigade it likes, including
>> it's own
>> custom developed buckets. The fact that brigades become heap buckets
>> when read is a property of our bucket brigades, they aren't a
>> restriction applied by the cache.
>> For example, in the large disk cache patch, a special bucket was
>> invented that represented a file that was not be completely present,
>> and that blocked waiting for more data if the in-flight cache
>> file was
>> not yet all there. There was no need to change the API to
>> support this
>> scenario, the cache just dropped the special bucket into the brigade
>> and it was done.
> Yeah, but in a tricky way, which is absolutely fine and cool if you cannot
> change the API, but the question is: Is this the way providers
> should go and does the API looks like as it should?
> Regards
> Rüdiger


I'm familiar with the FILE bucket and have considered implementing a new 
bucket type that would have similar morphing properties for our custom 3rd 
party cache provider.

Currently a handler has the ability to call ap_pass_brigade multiple times 
hence can produce large bodies in small chunks.  The CACHE_OUT filter as 
currently implemented does not offer that, forcing a 3rd party provider to 
implement their own bucket type if HEAP buckets would occupy too much 

Changing CACHE_OUT filter to call recall_body() repeatedly until an EOS is 
obtained is a small change.  More importantly, it won't affect existing 
providers as they'll produce a brigade with an EOS bucket on their first 

Custom bucket types may be a better approach, but shouldn't the CACHE_OUT 
filter be able to send the content in multiple brigades in the same way a 
handler would?


View raw message