[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: async mod_proxy_http

> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <ylavic.dev@xxxxxxxxx>
> Gesendet: Donnerstag, 13. September 2018 01:59
> An: httpd-dev <dev@xxxxxxxxxxxxxxxx>
> Betreff: Re: async mod_proxy_http
> On Wed, Sep 12, 2018 at 5:53 PM Eric Covener <covener@xxxxxxxxx> wrote:
> >
> > Forking from the Cool Stuff thread.
> >
> > Have you noticed that the wstunnell stuff makes the suspended count in
> > the MPM grow? There is no API for us to tell the MPM that when we get
> > the socket-activity callback that we are "resuming" something.
> >
> > (going from vague recollection)
> It seems that we increment it once when the handler returns SUSPENDED,
> and decrement it once per connection too in proxy_wstunnel_finish().
> However, looks like there is unnecessary churn
> proxy_wstunnel_finish(), including a double close since the MPM will
> also finally close the client connection. How about something like the
> attached?

I don't like the "misuse" of c->aborted here. I for instance log in the access log whether connections have been aborted or not and this approach would mean that all proxied websocket connections would get marked as aborted. Can't we use any other flag to tell the MPM to close the socket and push the pool, e.g. a note in c->notes?
Why is the lingering close no longer needed?
Why now doing ap_mpm_resume_suspended after ap_finalize_request_protocol(baton->r) and ap_process_request_after_handler(baton->r)?