(I split these up, since answers touch on different topics):

> Am 21.10.2015 um 16:48 schrieb Graham Leggett <minf...@sharp.fm>:
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> 
> wrote:
>> How good does this mechanism work for mod_http2? On the one side it's the 
>> same, on the other quite different.
>> On the real, main connection, the master connection, where the h2 session 
>> resides, things are
>> pretty similar with some exceptions:
>> - it is very bursty. requests continue to come in. There is no pause between 
>> responses and the next request.
>> - pauses, when they happen, will be longer. clients are expected to keep 
>> open connections around for
>> longer (if we let them).
>> - When there is nothing to do, mod_http2 makes a blocking read on the 
>> connection input. This currently
>> does not lead to the state B) or C). The worker for the http2 connection 
>> stays assigned. This needs
>> to improve.
> The blocking read breaks the spirit of the event MPM.
> In theory, as long as you enter the write completion state and then not leave 
> until your connection is done, this problem will go away.
> If you want to read instead of write, make sure the CONN_SENSE_WANT_READ 
> option is set on the connection.

This does not parse. I do not understand what you are talking about. 

When all streams have been passed into the output filters, the mod_http2 
session does a 

    status = ap_get_brigade(io->connection->input_filters,...)  (h2_conn_io.c, 
line 160)

similar to what ap_read_request() -> ap_rgetline_core() does. (protocol.c, line 

What should mod_http2 do different here?


Reply via email to