On 3/22/20 6:43 PM, Yann Ylavic wrote:
> +APR_BRIGADE_INSERT_TAIL(ctx->tmp_bb, bucket);
> +if (do_pass
> +|| APR_BRIGADE_EMPTY(ctx->bb)
> +|| (bucket->length == (apr_size_t)-1)
How can we have a bucket length of -1 here?
What about flush buckets?
On Thu, Jan 23, 2020 at 8:23 AM Pluem, Ruediger, Vodafone Group
wrote:
> >
> > https://github.com/apache/httpd/pull/88
>
> Anyone had a look?
If I understand the patch correctly, ap_request_core_filter() would
let everything through on EOR, regardless of potential morphing
buckets set aside?
So i
> Am 09.01.2020 um 12:39 schrieb Pluem, Ruediger, Vodafone Group
> :
>
>
>
>> -Ursprüngliche Nachricht-
>> Von: Stefan Eissing
>> Gesendet: Donnerstag, 9. Januar 2020 11:51
>> An: dev@httpd.apache.org
>> Betreff: Re: worker MPM test fai
> Am 09.01.2020 um 11:32 schrieb Pluem, Ruediger, Vodafone Group
> :
>
>
>
>
> C2 General
>
>> -Ursprüngliche Nachricht-
>> Von: Yann Ylavic
>> Gesendet: Mittwoch, 8. Januar 2020 16:48
>> An: httpd-dev
>> Betreff: Re: work
On Wed, Jan 8, 2020 at 8:36 AM Ruediger Pluem wrote:
>
> Just for my further analysis let me try to get the purpose of the
> ap_request_core_filter:
>
> It should leverage at least parts of the benefits of the filter setaside /
> yielding / brigade reinstate framework for
> filters that do not us
On Tue, Jan 07, 2020 at 07:31:42PM +0100, Yann Ylavic wrote:
> Could you please try the attached patch?
> The goal is to make ap_request_core_filter() a connection filter, so
> that it remains in c->output_filters until the EOR is handled.
> The patch has subtleties, but ap_request_core_filter() is
On 01/07/2020 07:31 PM, Yann Ylavic wrote:
> On Tue, Jan 7, 2020 at 5:06 PM Joe Orton wrote:
>>
>> This is a classic heisenbug since it is timing related, when you add
>> more debugging it slows the server down enough that the client can keep
>> up, write never returns EAGAIN, and the bug disap
On Tue, Jan 7, 2020 at 5:06 PM Joe Orton wrote:
>
> This is a classic heisenbug since it is timing related, when you add
> more debugging it slows the server down enough that the client can keep
> up, write never returns EAGAIN, and the bug disappears, I think...
OK, that explains why I can't rep
This is a classic heisenbug since it is timing related, when you add
more debugging it slows the server down enough that the client can keep
up, write never returns EAGAIN, and the bug disappears, I think...
I see from 2016 people have reported similar failures before ("Subject:
Some test failu