httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jagunet.com>
Subject Re: http://svn.apache.org/viewvc?view=rev&revision=602469
Date Sat, 08 Dec 2007 18:12:06 GMT

On Dec 8, 2007, at 11:39 AM, Ruediger Pluem wrote:
>
> In fact the patch does all this as it passes the passbb brigade down
> the chain after *each* processed bucket of the original brigade
> (the ap_pass_brigade is at *the end* of the while loop *not* after
> the while loop).

I didn't catch that when looking over the actual patch itself. Seeing
the actual code in trunk, yeah, this is better.

> So we don't process the whole brigade before passing it down the
> chain which would be indeed insane.
> In fact flush buckets are handled in the same manner as before
> the patch as they fall in the
>
> if (APR_BUCKET_IS_METADATA(b))
>
> branch and the next code that is executed after the block there
> is an ap_pass_brigade at the end of the while loop
>
>> I also see that AP_MIN_BYTES_TO_WRITE is no longer being
>
> I saw no need for us to do *any* buffering in the filter. If the
> data passed down the chain is not reasonable large for sending over
> the wire the core network filter will take care of this and buffer
> it until it is reasonable or a flush bucket is seen.
>
>> used at all... I'm guessing MAX_BUCKETS is designed to
>> "replace" that?? Again, the idea is to avoid extremely
>> large in-process data sizes :) The MAX_BUCKETS seems
>
> The patch does that :-).
>
>> to be mostly for super-bad cases and not so much for
>> behaving "nicely" in all cases. (mod_include.c does
>> the same thing, btw)
>
> No MAX_BUCKETS should not replace that. It is a safety measure
> for super bad cases like the example I gave in my initial review
> mail
> (http://mail-archives.apache.org/mod_mbox/httpd-dev/200712.mbox/% 
> 3c99EA83DCDE961346AFA9B5EC33FEC08B05B290@VF- 
> MBX11.internal.vodafone.com%3e).
>
> Regards
>
> RĂ¼diger
>
>
>


Mime
View raw message