(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
236)
What should mod_http2 do different here?
//Stefan
