On Tue, Jul 2, 2019 at 7:38 AM Stefan Eissing <[email protected]> wrote: > > > > > Am 02.07.2019 um 13:35 schrieb Eric Covener <[email protected]>: > > > > On Tue, Jul 2, 2019 at 4:51 AM Stefan Eissing > > <[email protected]> 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?
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. 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? 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. 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. -- Eric Covener [email protected]
