On Fri, 03 Dec 2004 18:07:12 -0500, Ronald Park <[EMAIL PROTECTED]> wrote: > And, given the problem described about long running request causing > children to potentially fall off the scoreboard, what happens in the > following scenario: > > Each of the X servers has 1 or more threads working on loooong requests. > > Other threads in each of those servers finish off M requests, meeting > (or exceeding?) MaxRequestsPerChild. (BTW, could you explain which > thread takes on responsibility for nicely shuting down the process? > The thread which pushed us past MaxRequestPerChild, the long running > thread (when it eventually finishes) or some 'master' thread?)
see server/mpm/worker/worker.c; a call to signal_threads() gets everybody to exit; that can be called in various conditions on different threads > Under these circumstances, the X children can't (yet) exit... but > there's still more requests coming in. And what happens when the > listen queue fills up in the parent? There is no listen queue in the parent. Incoming connections are queued only in the kernel before a thread in a child process calls accept(). In this [basket] case, you have MaxClients child processes, each with one thread processing an active request; there are no listener threads since the processes are in the act of exiting and the listener thread exits in that case, so everything queues up in the kernel until the kernel accept queue overflows. This is similar in effect to What happens in the more normal MaxCLients conditions: Listener threads won't exit, but they will refuse to accept more connections if there is no thread available to process the connection, so everything queues up in the kernel until the kernel accept queue overflows. This, like other MaxClients conditions, ends when a request ends.
