Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <003401c1e19c$9bfa1450$6501a8c0@sashimi>
From: "Bill Stoddard" <bill@wstoddard.com>
To: <dev@httpd.apache.org>
References: <20020409225116.G26866@clove.org>
 <64BB55FA-4CC6-11D6-934C-000393753936@apache.org>
 <20020410141800.Z26866@clove.org> <m3vgaytowm.fsf@rdu88-250-035.nc.rr.com>
 <3CB59EC4.5010703@pacbell.net> <20020411095518.Y26866@clove.org>
 <00eb01c1e17c$17422650$1b381b09@sashimi>
 <00f301c1e17c$60de72f0$1b381b09@sashimi> <3CB5CDED.2050206@cnet.com>
 <013001c1e18b$b695f830$1b381b09@sashimi> <20020411130622.F26866@clove.org>
Subject: Re: [PATCH] convert worker MPM to leader/followers design
Date: Thu, 11 Apr 2002 17:05:23 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> On Thu, Apr 11, 2002 at 03:04:27PM -0400, Bill Stoddard wrote:
> > I am not an expert on the worker MPM but I don't think that is an accurate statement
of
> > the problem.  The accept thread uses ap_queue_push() to enqueue a socket for the
worker
> > threads. ap_queue_push() will block if the queue is full.
> >
> > The problem is that the queue can be EMPTY even when all the worker threads are busy
> > handling connections.  The way the code is today, the queue can hold
ap_threads_per_child
> > elements. Now consider 2 x ap_threads_per_child connections comming into the server at
> > once.. The first 1 x ap_threads_per_child connections will be accepted and handled by
the
> > worker threads. The next ap_threads_per_child connections will get queued and this is
> > precisely the problem...
>
> Now I know I'm missing something here, so maybe you can fill in the
> blanks for me. This doesn't seem like a problem that would hang the
> entire server or put a hard limit on the number of concurrent connections
> (across processes). I would expect a finishing worker thread to return
> to the queue and immediately try to pick up an accepted and queued
> connection, waking up the listener thread if it was waiting for a slot
> to free up in the queue. Is this not the case? Where does the listener
> thread block in such a way that it prevents other idle threads from
> processing incoming requests?
>
> -aaron

That sounds like a bug in the worker queue code (preventing the accept thread from being
awakened if the queue is 'almost' full...)

Bill