You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2018/09/12 15:53:24 UTC
async mod_proxy_http
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)
--
Eric Covener
covener@gmail.com
Re: async mod_proxy_http
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Sep 13, 2018 at 1:59 AM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Wed, Sep 12, 2018 at 5:53 PM Eric Covener <co...@gmail.com> 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().
Besides this, don't we want suspended/resumed connection to have their
scoreboard status change?
No particular idea of how we'd do this but looks sensible to me to be
able to see how many suspended (or not) connections there are.
Regards,
Yann.
AW: async mod_proxy_http
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Eric Covener <co...@gmail.com>
> Gesendet: Donnerstag, 13. September 2018 02:34
> An: Apache HTTP Server Development List <de...@httpd.apache.org>
> Betreff: Re: async mod_proxy_http
>
> On Wed, Sep 12, 2018 at 7:59 PM Yann Ylavic <yl...@gmail.com>
> wrote:
> >
> > On Wed, Sep 12, 2018 at 5:53 PM Eric Covener <co...@gmail.com>
> 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().
>
> This didn't even ring a bell :)
>
> But won't we return SUSPENDED many times to a single finish?
Not really, because once we are suspended we only get triggered by timer events
until we leave this state in proxy_wstunnel_finish.
Regards
Rüdiger
Re: async mod_proxy_http
Posted by Eric Covener <co...@gmail.com>.
On Wed, Sep 12, 2018 at 7:59 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Wed, Sep 12, 2018 at 5:53 PM Eric Covener <co...@gmail.com> 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().
This didn't even ring a bell :)
But won't we return SUSPENDED many times to a single 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?
Looks reasonable.
AW: async mod_proxy_http
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <yl...@gmail.com>
> Gesendet: Donnerstag, 13. September 2018 12:24
> An: httpd-dev <de...@httpd.apache.org>
> Betreff: Re: async mod_proxy_http
>
> On Thu, Sep 13, 2018 at 10:55 AM Plüm, Rüdiger, Vodafone Group
> <ru...@vodafone.com> wrote:
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Yann Ylavic <yl...@gmail.com>
> > > Gesendet: Donnerstag, 13. September 2018 10:37
> > > An: httpd-dev <de...@httpd.apache.org>
> > > Betreff: Re: async mod_proxy_http
> > >
> > > On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group
> > > <ru...@vodafone.com> wrote:
> > > >
> > > > 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?
> > >
> > > Agreed, let lingering close do its job if the client connection is
> not
> > > closed already.
> > > Better in v2 (attached)?
> >
> > Better. Should a module outside the core directly fiddle around with
> > the connection state in this case setting it to CONN_STATE_LINGER?
>
> I'd said no... but for modules playing async with the MPM :p
> One way or another we need a flag which is meant for the MPM at
> resume_suspended time (be it the state, a c->notes, ...), and that
> hook is likely to be called by modules going async...
So we lack some clearly defined API here?
If yes shouldn't one defined?
Regards
Rüdiger
Re: async mod_proxy_http
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Sep 13, 2018 at 10:55 AM Plüm, Rüdiger, Vodafone Group
<ru...@vodafone.com> wrote:
>
> > -----Ursprüngliche Nachricht-----
> > Von: Yann Ylavic <yl...@gmail.com>
> > Gesendet: Donnerstag, 13. September 2018 10:37
> > An: httpd-dev <de...@httpd.apache.org>
> > Betreff: Re: async mod_proxy_http
> >
> > On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group
> > <ru...@vodafone.com> wrote:
> > >
> > > 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?
> >
> > Agreed, let lingering close do its job if the client connection is not
> > closed already.
> > Better in v2 (attached)?
>
> Better. Should a module outside the core directly fiddle around with
> the connection state in this case setting it to CONN_STATE_LINGER?
I'd said no... but for modules playing async with the MPM :p
One way or another we need a flag which is meant for the MPM at
resume_suspended time (be it the state, a c->notes, ...), and that
hook is likely to be called by modules going async...
Regards,
Yann.
>
> >
> > > Why now doing ap_mpm_resume_suspended after
> > > ap_finalize_request_protocol(baton->r) and
> > > ap_process_request_after_handler(baton->r)?
> >
> > I think we don't want EOS/EOR filtering race with the MPM on the
> > connection...
> >
>
> Fair enough.
>
> Regards
>
> Rüdiger
>
AW: async mod_proxy_http
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <yl...@gmail.com>
> Gesendet: Donnerstag, 13. September 2018 10:37
> An: httpd-dev <de...@httpd.apache.org>
> Betreff: Re: async mod_proxy_http
>
> On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group
> <ru...@vodafone.com> wrote:
> >
> > 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?
>
> Agreed, let lingering close do its job if the client connection is not
> closed already.
> Better in v2 (attached)?
Better. Should a module outside the core directly fiddle around with the connection state in this case setting it to CONN_STATE_LINGER?
>
> > Why now doing ap_mpm_resume_suspended after
> > ap_finalize_request_protocol(baton->r) and
> > ap_process_request_after_handler(baton->r)?
>
> I think we don't want EOS/EOR filtering race with the MPM on the
> connection...
>
Fair enough.
Regards
Rüdiger
Re: async mod_proxy_http
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group
<ru...@vodafone.com> wrote:
>
> 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?
Agreed, let lingering close do its job if the client connection is not
closed already.
Better in v2 (attached)?
> Why now doing ap_mpm_resume_suspended after
> ap_finalize_request_protocol(baton->r) and
> ap_process_request_after_handler(baton->r)?
I think we don't want EOS/EOR filtering race with the MPM on the connection...
Regards,
Yann.
AW: async mod_proxy_http
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic <yl...@gmail.com>
> Gesendet: Donnerstag, 13. September 2018 01:59
> An: httpd-dev <de...@httpd.apache.org>
> Betreff: Re: async mod_proxy_http
>
> On Wed, Sep 12, 2018 at 5:53 PM Eric Covener <co...@gmail.com> 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)?
Regards
Rüdiger
Re: async mod_proxy_http
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Sep 12, 2018 at 5:53 PM Eric Covener <co...@gmail.com> 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?
Regards,
Yann.