httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: buckets and connections (long post)
Date Thu, 22 Oct 2015 15:43:20 GMT
(I split these up, since answers touch on different topics):



> Am 21.10.2015 um 16:48 schrieb Graham Leggett <minfrin@sharp.fm>:
> 
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing <stefan.eissing@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
Mime
View raw message