On Friday 27 July 2001 11:50, Jeff Trawick wrote:
> Ryan Bloom <[EMAIL PROTECTED]> writes:
> > Unless somebody objects, I will commit my latest patch to the threaded
> > MPM later this weekend. This is the patch that implements a multi-process
> > single acceptor/multi-worker model. This will allow us to finish fixing
> > the threaded MPM.
>
> How does this affect having more than one process trying to take over
> the slots of a process which is going away?
It doesn't.
> What happens with graceful restart? Is there a limit on the number
> of requests which will be served using the old configuration? (That
> is something which I thought sucked with my
> accept-thread/worker-thread MPM... I'm interested in how this problem
> is approached.)
The way the threaded MPM currently works, and this patch continues the current model
follows:
the process starts, and creates a bunch of worker threads.
When we get a graceful restart request, all the workers are supposed to die unless
they are
serving a request. (this does not work today, but can actually be implemented with
the single
listener/multi-worker)
A new process is started as soon as the old process kills the first thread.
The new process watches as other threads die, and creates new threads to fill those
spots
in the scoreboard. Because we are watching for old threads to die, we do not fight
over
worker slots.
When the last thread dies in the original process, that process dies, and the new
process takes
over for good.
This is how it is continued to be approached with the new patch. This means that we
finish serving
the current connections when we get a graceful restart, but do not accept any new ones.
This new model (actually the original threaded model for Apache 2.0) allows us to
actually finish
fixing graceful restarts in the threaded MPM. The current model makes it impossible
to cleanly shut
down threads that are sitting in locks, so gracefully shutting down a child process is
not currently possible.
Ryan
_____________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
-----------------------------------------------------------------------------
