httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Single listener - multi-worker
Date Fri, 27 Jul 2001 19:26:04 GMT
Ryan Bloom <rbb@covalent.net> writes:

> On Friday 27 July 2001 11:50, Jeff Trawick wrote:
> > Ryan Bloom <rbb@covalent.net> 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 | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message