"Plüm, Rüdiger, VF-Group" wrote: > > >> -----Original Message----- >> From: Graham Leggett >> Sent: Montag, 13. September 2010 16:35 >> To: dev@httpd.apache.org >> 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
Hi, 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 memory. 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 invocation. 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? Thanks, Paul
