> -----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. Regards Rüdiger
