httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: svn commit: r467655 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/mod_cache.c modules/cache/mod_cache.h
Date Wed, 25 Oct 2006 18:02:56 GMT
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

Mime
View raw message