Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 23687 invoked by uid 6000); 4 May 1999 07:01:58 -0000 Received: (qmail 23663 invoked from network); 4 May 1999 07:01:55 -0000 Received: from dillinger.io.com (manojk@199.170.88.20) by taz.hyperreal.org with SMTP; 4 May 1999 07:01:55 -0000 Received: (from manojk@localhost) by dillinger.io.com (8.9.1/8.9.1a) id CAA28952 for new-httpd@apache.org; Tue, 4 May 1999 02:01:53 -0500 (CDT) Date: Tue, 4 May 1999 02:01:52 -0500 From: Manoj Kasichainula To: new-httpd@apache.org Subject: Re: fix for hybrid server problems. Message-ID: <19990504020152.B27914@io.com> Mail-Followup-To: new-httpd@apache.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Dean Gaudet on Mon, May 03, 1999 at 12:05:22PM -0700 Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org I'm reordering Dean's ideas, from easiest to hardest. :) On Mon, May 03, 1999 at 12:05:22PM -0700, Dean Gaudet wrote: > MaxRequestsPerChild (perthread, whatever) are best guesses. We > don't guarantee that we'll hit them dead on. When a worker thread > notices MaxRequestsPerChild has been hit, it sends an event to the > event thread, the event thread initiates a graceful shutdown of > the child process. This is actually all true right now, just done in a different way. MaxRequestsPerChild handling isn't mutexed, so we can miss a few decrements of requests_this_child. And, once we've hit MaxRequestsPerChild, we raise SIGWINCH, and try to convince our threads to die. It would be nice to replace this with a pipe, though. > Add a new API phase -- "graceful shutdown". This is invoked when > the parent asks the process to shutdown -- remember to a httpd child > there is no distinction between graceful shutdown or graceful restart. > When the graceful shutdown occurs, modules (and the core) should close > up any resource which might prevent another instance of the webserver > from starting... such as listening sockets. Can we rely on close() or shutdown() getting rid of our listening sockets while we're selecting on them? > graceful restart and graceful shutdown are the two suggested forms > of restarting and shutting down the server. They're the safe forms. If we solve the above problem (and log rotation), this sounds reasonable. Do we mind that there will be no way to get a mod_status display of our gracefully dying children after a graceful shutdown? > logging: yeah, there is difficulty with log rotation if graceful > restart is the only restart available -- there's no way for an > external program to know that all children have finished writing > the rotated logs. There's a few possibilities for solving this... Do the words "reliable", "piped", and "logs" get used, in that order? > You'll be surprised to hear me bring up an acceptor thread again... but > I have a reason for returning its existance: to service static requests. It sounds cooler and cooler the more I think about it (which isn't much yet), but I really was hoping to get rid of that intervening request queue. :( Well, at least with only one thread doing the pushing on that queue, we can get rid of a pair of mutex calls. -- Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/ "Would you die for The One?" "I wouldn't get pizza for the one. That ain't my job." - J.M. Straczynski