> Am 02.07.2019 um 13:35 schrieb Eric Covener <cove...@gmail.com>:
>
> On Tue, Jul 2, 2019 at 4:51 AM Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
>>
>> People with in insight into your connection state handling, please review:
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63534
>>
>> describes an issue with HTTP/2 and KeepAliveTimeout. Basically, HTTP/2
>> writes response DATA, gets blocked on HTTP/2 flow control,
>> and makes a blocking READ on the connection. Since the only thing that can
>> move things forward is a packet from the client.
>>
>> This triggers the KeepAlive behaviour of our connections, which is not what
>> should apply here. The alternatives I can see are:
>> 1. non-blocking reads and therefore continue to block a worker
>> 2. twiddle the server->keepalive setting, question is, will that influence
>> the mpm?
>
> Is it actually keepalive behavior/processing or just the servers
> keepalive timeout explicitly set before the outstanding read on the
> master connection?
>
> I don't exactly follow how, but it seems like w/ event mod_h2 already
> knows how to suspend/resume based on CONN_STATE_WRITE_COMPLETION when
> the session thread knows it's idle too long.
> But maybe there is an issue in how the connection handler returns and
> event goes into lingering close instead?
What I think is happening is that connection state is
CONN_STATE_WRITE_COMPLETION and h2 does a BLOCKing read on the main connection.
After the write has been completed, the keepalive handling applies to the
connection - and pre-close()/linger()/closes it.
But the HTTP/2 state is not suitable for keepalive, just timeout. Is there a
way to avoid that?
>
> (sorry if I am totally misunderstanding)
