> -----Ursprüngliche Nachricht----- > Von: Pluem, Ruediger, Vodafone Group <ruediger.pl...@vodafone.com> > Gesendet: Donnerstag, 9. Januar 2020 11:32 > An: dev@httpd.apache.org > Betreff: AW: worker MPM test failures (was Re: Still Failing: > apache/httpd#190 (trunk - 894b6a1)) > > > > > 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: > > > > > > 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
Anyone had a look? Regards Rüdiger
