Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <475AC8CB.3030909@apache.org>
References: <D17CF68E-1AA2-48C4-A6D6-0DCD28049E84@jaguNET.com>
 <475AC8CB.3030909@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <5690D3FB-3FDB-4DC5-AC3C-7049AB45D4F5@jagunet.com>
Content-Transfer-Encoding: quoted-printable
From: Jim Jagielski <jim@jagunet.com>
Subject: Re: http://svn.apache.org/viewvc?view=rev&revision=602469
Date: Sat, 8 Dec 2007 13:12:06 -0500
To: dev@httpd.apache.org


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/%=20
> 3c99EA83DCDE961346AFA9B5EC33FEC08B05B290@VF-=20
> MBX11.internal.vodafone.com%3e).
>
> Regards
>
> R=FCdiger
>
>
>