httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF EITO <>
Subject Re: Possible new cache architecture
Date Wed, 03 May 2006 12:07:44 GMT

> -----Ursprüngliche Nachricht-----
> Von: Joe Orton 
> The way I would expect it to work would be by passing f->next 
> in to the 
> store_body callback, it looks doomed to eat RAM as currently 
> designed. 
> mod_disk_cache's store_body implementation can then do:
>  1. read bucket(s) from brigade, appending to some temp brigade
>  2. write bucket(s) in temp brigade to cache file
>  3. pass temp brigade on to f->next
>  4. clear temp brigade to ensure memory is released
>  5. goto 1

Yes, this was also my idea, but I would like to avoid this, because:

1. This is an API change which might be hard to backport.
2. I do not really like the close tie between the storage provider
   and the filter chain. It forces the provider to do things it
   should not care about from my point of view.
   Furthermore: What about mod_cache in this case? Do you want to
   skip ap_pass_brigade there or do you want to cleanup the original
   brigade inside store_body of mod_disk_cache and let mod_cache pass
   an empty brigade up the chain?
   If we decide to skip ap_pass_brigade inside mod_cache all storage
   providers need to ensure that they pass the data up the chain
   which seems duplicated code to me and does not seem to belong to
   their core tasks.
   OTH doing this in mod_cache and only pass the small brigade to
   store_body of the provider has the drawback that mod_mem_cache wants
   to see the original file buckets in order to save the file descriptors
   of the files.
   To be honest, currently I have no solution at hand that I really like,
   but I agree that this really needs to be changed.



View raw message