httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: Single listener - multi-worker
Date Fri, 27 Jul 2001 19:43:34 GMT
> 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

Since we can only buffer up the ThreadsPerChild, this is easily solved,
by just having the workers check the backlog before they exit.  If there
is something in the buffer area, then it takes one request, and serves it.

> > 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

See above

>
> > 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.

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------

Mime
View raw message