Hunting a bit on the "scoreboard is full, not at MaxRequestWorkers" issue,
I found that setting
c->cs->state = CONN_STATE_LINGER;
explicitly on exiting connection processing (h2_conn.c) seems to help
with this. As an experiment, I set
c->cs->state = CONN_STATE_READ_REQUEST_LINE;
and observed ever increasing memory use by the processes. With setting
state to CONN_STATE_LINGER explicilty, I have stable memory use and have
not seen a full scoreboard since.
I have my theory of what goes wrong below, maybe someone with a better
understanding of mpm_event wants to run this through her head...
Maybe connection state on finishing processing needs to be checked
either better, or the code in mpm_event needs to become more robust.
//Stefan
------------------------------------------------------------------------------
Although I had not configured MaxRequestsPerChild, someone decided that
the child process should close its listener gracefully. In event.c
listener_may_exit is set and the listener is woken up.
The listener sees this, sets all to close and since it is gracefully,
if checks if any connections are still open.
This is the case if the connection pools are not cleaned up properly!
Without cleanup, the connection counter in event.c is never decremented
and the child process will never exit. In the server-status, this is
visible as all workers of a process in state 'G', which never changes.
And sometime later the "scoreboard is full" log message will come...
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
