Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis

[Ruediger Pluem]

On 3/26/20 12:11 AM, Graham Leggett wrote:
> On 24 Mar 2020, at 11:47, Joe Orton <jor...@redhat.com> wrote:
> 
>> On Tue, Mar 24, 2020 at 12:35:45AM +0200, Graham Leggett wrote:
>>> The most likely reason is because:

> 
>>  If this is the correct default I guess I'd ask 
>> why isn't this hard-coded - at least maybe for affected MPMs?  Maybe try 
>> it and see if the Travis failures go away.
> 
> It is not the correct default, no.
> 
> What it does do is work around buggy request filters (set it to connection) 
> or buggy connection filters (set it to network and get 2.4 behaviour)..
> 
> Set AsyncFilter appropriately and you’ll at least narrow it down.
> 
> The question you’re asking is “why is is an async path being taken when 
> AP_MPMQ_IS_ASYNC is false”. The setasides and reinstates should be noops in 
> this situation.

Having the setasides and reinstates as noops in this situation might help, but 
as far as I can tell they make no difference
whether the MPM is sync or async.
What makes you think that an async path is taken?
Setting AsyncFilter to connection will very likely help (not tested yet) as it 
effectively removes the ap_request_core_filter.

Regards

Rüdiger