httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: FLUSH, filtering, setaside, etc (was Re: Problems with EOS optimisation in ap_core_output_filter() and file buckets.)
Date Wed, 18 Feb 2009 20:39:31 GMT

On 02/18/2009 11:16 AM, Joe Orton wrote:
> On Mon, Feb 16, 2009 at 03:12:11PM +0100, Ruediger Pluem wrote:
>> On 02/16/2009 02:13 PM, Joe Orton wrote:
>>> Why is it invalid use of the filtering/buckets API to close the file 
>>> after sending the FILE-containing brigade up the filter stack?  
>>> It seems counter-intuitive to me that *anything* you do after the 
>>> ap_pass_brigade() call should make a difference to what was passed up 
>>> the filter stack.  But I suppose this is the case; even most of the 
>>> memory-backed bucket types don't duplicate referenced memory in the 
>>> setaside method.
>> I guess this is not needed in most cases and is not done for performance
>> reasons. But maybe we can change the setaside for file buckets to do
>> an additional dup on the fd.
> The choices seem to be:
> 1) declare the FLUSH to be be necessary in this case as you said 
> originally ;) - and document appropriately
> 2) rewrite/reinvent all the setaside methods to dup/copy as appropriate
> 3) declare the core output filter broken and fix it
> Of these (2) and (3) will presumably have some negative performance 
> impact though I'm not sure to what degree.  Not sure (2) is even going 
> to be possible, e.g. with MMAP buckets, scary stuff.

Yes, I don't know how MMAP would work with this, so dup might be a bad
approach regarding this. In any case it looks like it would cause a lot
of trouble until working stable again :-)

> Looking at the cray-zee non-blocking core output filter on the trunk, it 
> will setaside with wild abandon unless it hits a FLUSH.  I think all 

There is still a nasty issue with the trunk code that can cause you to
run out of FD's as the new non blocking core output filter has some trouble
setting aside the file buckets to the correct pool (it puts them in the
connection pool which is too long living and bad).

See thread starting at

I admit that I lost momentum on this, but this definitely needs to be fixed.

> these options are pretty distasteful but (1) seems like the only 
> feasible route.  What do you think?  

I guess at least for the moment (1) is the way to go exactly for the
reasons you stated.



View raw message