AW: worker MPM test failures (was Re: Still Failing: apache/httpd#190 (trunk - 894b6a1))

[Pluem, Ruediger, Vodafone Group]

C2 General

> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <ylavic....@gmail.com>
> Gesendet: Mittwoch, 8. Januar 2020 16:48
> An: httpd-dev <dev@httpd.apache.org>
> Betreff: Re: worker MPM test failures (was Re: Still Failing:
> apache/httpd#190 (trunk - 894b6a1))
> 
> On Wed, Jan 8, 2020 at 8:36 AM Ruediger Pluem <rpl...@apache.org> 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 use this, because e.g.
> >
> > - they are not aware of this framework
> 
> Yes, the goal (I think, Graham could confirm) is to let request
> filters work as before but have a catch all (last) filter to not let
> morphing buckets go through connection filters (and consume c->pool).
> Same for setasides.
> 
> > - it seems to complex for them to use it and adjust their filter
> >
> > Of course this is not perfect as some resource and content filters
> need to handle this on their own e.g. deflate when
> > compressing contents of file buckets in order to avoid blocking
> writes.
> 
> Correct.
> 
> >
> > Thinking out loudly a bit here: Except for ap_request_core_filter all
> other resource and content filters should process
> > all the data they might have setaside when they see an EOS in a
> brigade, correct?
> 
> I think so, because otherwise they will never be called again since
> the core/mpm only cares about connection filters, so the data must be
> there after EOS. In any case, request filters shall not be called when
> EOR is in the place.
> 
> 
> Regarding my patch, I'm afraid it's not the right fix, we can't front
> push several req_core output filters like this.
> If an old/outer req_core filter has to setaside buckets (network
> EAGAIN) while the passed brigade contains buckets from the new
> request, then it will setaside the buckets from a newer request pool
> to an oldest's.
> Even though it can (possibly) work, it does not look quite optimal,
> we'd need some kind of Start Of Request (SOR) bucket to delimit
> buckets from/for successive requests. SOR would be passed through
> c->output_filters when a new request is created (e.g. in
> http_create_request()), since anything sent through the request
> filters from that time should be about this last request.
> Then a single req_core connection filter could be responsible for
> setting aside buckets on the relevant request pool (should some
> congestion occur).
> 
> Dunno if we want to go that route, though...

As this looks like to be a larger amount of work I come back to my simple patch 
idea
that would possibly cause more blocking writes, but would ensure that the data 
is sent
completely at least. Basically it pushes all down the chain once it notices an 
EOR bucket.
See

https://github.com/apache/httpd/pull/88

BTW: Can we really have morphing buckets in ap_request_core_filter? 
ap_request_core_filter runs
after a possible HTTP chunking filter that I guess needs to be in place when we 
have a morphing
bucket which makes it impossible to determine the content length upfront. Hence 
I guess the
HTTP chunking filter will transform all these morphing buckets already.
Or is this just a safety measure to support other protocols but HTTP?

Regards

Rüdiger