Eric,
thanks for the quick reply. follow-up inline below:
On 1/27/24 09:46 PM, Eric Covener wrote:
apache2: 2.4.56-1~deb11u2, prefork MPM, mod_perl
I think it's a large window on prefork where this can happen. If any
process is busy processing a request, it cannot close its copy of the
listening socket. The OS will continue to complete TCP connections and
acknowledge (some) data with nobody calling accept(). When the last
of the listening sockets is finally closed, the TCP connections that
arrived in this timeframe will be abruptly closed.
is this window essentially the time between when the parent process
calls close() on its copy of the listening socket and when the last of
the child processes is handling its request and can call close() on the
last remaining copy of the listening socket? if so, then it sounds like
the window becomes wider and this situation becomes more likely if the
children are handling longer-running requests.
Both worker and event MPMs have a dedicated listener thread per child
process, so it will close those copies of the listening sockets much
more quickly.
so that i am clear, are you saying that this behavior is still possible,
although less likely under the worker and event MPMs?
NVM, actually, it appears that i may have already answered this question
by not paying enough attention to detail when setting up my test
environment. i unintentionally replicated the behavior under the event
MPM when my intention was to use prefork for the sake of consistency.
but i would still like to better understand "how much" the window is
reduced under worker and event. for example, would they be
similarly-effected by a child that is still handling a long-running
request, or would the listener thread be able to close() its copy of the
socket while the handling thread is still serving content to the client?
thanks again
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
