Joe Orton wrote: > On Wed, Oct 25, 2006 at 01:54:04PM -0300, Davi Arnaut wrote: >> Joe Orton wrote: >>> Another couple of hundred lines of code and even a new config directive, >>> and this still doesn't get close to actually fixing the problem! -1 >>> already, this code is just not getting better. mod_disk_cache is still >>> liable to eat all your RAM in that apr_bucket_read() loop, the >>> apr_bucket_split() is not guaranteed to work for a morphing bucket type. >>> >>> It is simple enough to fix this problem without adding all this code and >>> without all the stuff in r450105 too, something like the below. >>> >> And you almost got it right. We don't want to stop caching if the >> client's connection fail > > ...a simple enough change.
Yes. >> and we must not slow the caching because of a slow client (that's why >> I didn't pass the brigade). > > There is no other acceptable solution AFAICS. Buffering the entire > brigade (either to disk, or into RAM as the current code does) before > writing to the client is not OK, polling on buckets is not possible, > using threads is not OK, using non-blocking writes up the output filter > chain is not possible. Any other ideas? I think we should build the necessary infrastructure to solve this problem once and for all. Be it either non-blocking writes, AIO or add support to the core output filter to write data to different destinations. -- Davi Arnaut
