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? (sorry if I am totally misunderstanding)
