Ryan Bloom <[EMAIL PROTECTED]> writes:
> 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.
> > 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 point here is that an accept thread picks up new connections from
the kernel in advance of a worker thread processing them. You can end
up with a backlog of requests. At graceful restart time this process
which needs to go away has already taken ownership of a certain number
of requests which must be processed before it can exit.
current threaded MPM:
once graceful restart is signalled, no new connections will be
accepted from the kernel so we start using the new configuration
ASAP
accept-thread/worker thread MPM:
likely there is a backlog of requests at the time graceful restart
is signalled; these have to be processed with the old configuration
>
> 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.
unlike with current MPM, worker threads can't die as soon as they
finish the current request... they have to stay around as long as we
have a backlog of accepted connections to process
> 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.
Which locks are problematic now for graceful restart? Which locks are
no longer problematic?
I thought it was non-graceful stop/restart we didn't know how to do.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
