That one works nicely in the test and load setups! +1
> Am 23.12.2017 um 17:37 schrieb Yann Ylavic <ylavic....@gmail.com>:
> On Fri, Dec 22, 2017 at 6:14 PM, Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
>> The changes in h2_h2.c and h2_switch.c work find in my test. However, the
>> change in h2_conn.c which sets CONN_STATE_LINGER does not. It prevents the
>> last GOAWAY frame from the server to be sent out, in some tests.
>> The current flow, when the client sends a GOAWAY is that the session
>> transits to H2_SESSION_ST_DONE, the mpm calls the pre_linger hook and
>> that writes the server's GOAWAY (as it does in situations where the
>> is shut down after an idle timeout by the mpm itself).
> Argh, forgot about the pre_close_connection hook..
>> mod_http2 also returns from connection procession when the connection
>> can only progress when more frames from the client arrive. For example,
>> when the session is H2_SESSION_ST_DONE, which means that all streams have
>> been processed. This is analog to a request being done on a h1 connection.
>> But the h2session and all its state is still alive. So c->aborted should
>> not be set. And it is definitely not in LINGER.
> Yes, the issue is probably not about CONN_STATE_LINGER, but c->aborted.
> I wanted to close the connection as quickly as possible, that was not
> a good idea.
> I could replace ap_flush_conn() by ap_lingering_close() in my patch,
> but the simpler is to let the MPM do it, v2 attached simply sets
> CONN_STATE_LINGER (it may be turned to CONN_STATE_WRITE_COMPLETION in
> the Upgrade case, still the MPM will do the right thing with
> c->keepalive = AP_CONN_CLOSE).
> My main concern was returning anything else than
> CONN_STATE_WRITE_COMPLETION or CONN_STATE_LINGER in h2_conn_run(),
> like CONN_STATE_HANDLER.
>> I am all for aligning h2 connection states more with the connection state
>> model that mpm_event has (and vice versa). Maybe we have to lock ourselves
>> into a room with a whiteboard and beers and figure this out one day...
> Would be a pleasure :)
>> Do we have good documentation about the CONN_STATE engine somewhere?
> I updated some comments in event.c lately...