httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: request SUSPENDED (was: [VOTE] backport mod_proxy_http2 to 2.4.x as experimental)
Date Fri, 11 Mar 2016 11:02:33 GMT
Comments to the later parts, re suspending requests.

> Am 10.03.2016 um 22:24 schrieb Yann Ylavic <>:
> [...]
> On Thu, Mar 10, 2016 at 5:38 PM, Stefan Eissing
> <> wrote:
>> Backend Engines
>> ---------------
>> How can we do that? Let's discuss one master http2 connection with
>> no proxy request ongoing. The next request which is handled by proxy_http2
>> is the "first" - it sees no other ongoing request against the same
>> backend. It registers itself at the master http2 session for the backend.
>> It performs the request in the usual way, de-registers itself again
>> and returns. Same as with HTTP/1, plus some registration dance of what
>> I named a "request engine".
>> If another worker handles a proxy_http2 request, while the "first"
>> engine is ongoing, it sees that someone has registered for the backend
>> that it also needs. What it then does is "hand over" the request_rec
>> to the "first" engine and immediately returns as if done.
> Which sends out the EOR since the core thinks the request is done, right?
> If so, wouldn't returning SUSPENDED be more appropriate (that would
> free the worker thread for some other work)?

Now I learned something new! Have to try this.

So, a handler may return SUSPENDED, which inhibits the EOR write and
sets the connection in state SUSPENDED as well and leaves the 
process_connection loop, but only with an async mpm. Right?

I assume that the resume handling is supposed to happen in the
in/out filters only then. How much of that is available in 2.4? I
saw that there are several improvements in trunk on that part...

But on the h2 slave connections, this could work in both branches. I 
will give this a shot.

>> [...]
>> When the proxy_http2 worker for that request returns, mod_http2
>> notices the frozen request, thaws it and signals the backend connection
>> worker that the request is ready for processing. The backend worker
>> picks it up, handles it and *closes the output* which will write
>> the buckets set aside before. This will write the EOR and the
>> request deallocates itself. During this time, all the input/output
>> filter etc. will remain in place and work.
> With my description above, that would translate to: before the worker
> thread available to handle the last bytes of a response sends them, it
> also flushes the EOR.
> Each worker thread could still do as much work as possible (as you
> describe) to save some queuing in the MPM, but that's possibly further
> optimization.

Still learning about all the interactions between MPM, event and core.
It's quite some code there...



View raw message