> Am 02.07.2019 um 14:00 schrieb Eric Covener <cove...@gmail.com>:
>
> On Tue, Jul 2, 2019 at 7:38 AM Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
>>
>>
>>
>>> 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?
>
Thanks for taking the time to discuss this. :)
> I think a successful exit of CONN_STATE_WRITE_COMPLETION would
> conceptually lead to keepalive state so that would be plausible. And
> a failed one would go into lingering close.
That is also how I understand it.
> This touches back to where I didn't really understand how h2 gets
> control back after explicitly yielding via
> CONN_STATE_WRITE_COMPLETION. Do you know if h2 currently/ever hops
> mpm threads this way successfully?
With the current mpm architecture, there are only two situations where
connection processing by h2 returns to the mpm:
1. when all streams(request) have been handled and the connection is really in
KeepAlive
2. when the flow-control windows of existing streams are exhausted. The only
thing that can unlock this state are new frames from the client.
My understanding is that the mpm either times out the connection or receives
client data which it then makes invoke connection processing again. Here, the
KeepAliveTimeout seems to alway apply which is wrong for the situation 2
described above.
> Another option is the pre-existing timed callabck
> ap_mpm_register_timed_callback() once you get into this stall where
> you really want to give a thread back but still have hope it might
> progress.
The problem is not a stall, but that mpm shuts down the connection too early.
Or I misunderstood your point...
> An option in this area is trunk-only PT_USER callback in event which
> frees you from shoehorning into the states and just lets you get
> called back when a socket is readable.
> This is what's used in mod_proxy_wstunnell in the opt-in async mode.
Hmm, I need to look at that. Thanks for the pointer.
Cheers, Stefan
> --
> Eric Covener
> cove...@gmail.com
