Return-Path: Delivered-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Received: (qmail 50025 invoked from network); 29 Dec 2010 08:52:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 29 Dec 2010 08:52:59 -0000 Received: (qmail 56564 invoked by uid 500); 29 Dec 2010 08:52:58 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 56305 invoked by uid 500); 29 Dec 2010 08:52:58 -0000 Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: modules-dev@httpd.apache.org Delivered-To: mailing list modules-dev@httpd.apache.org Received: (qmail 56297 invoked by uid 99); 29 Dec 2010 08:52:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Dec 2010 08:52:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mwm-keyword-apache.b9a3c0@mired.org designates 74.143.213.42 as permitted sender) Received: from [74.143.213.42] (HELO mired.org) (74.143.213.42) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Dec 2010 08:52:53 +0000 Received: (qmail 61727 invoked by uid 501); 29 Dec 2010 03:52:32 -0500 Received: from bhuda.mired.org (192.168.195.96) by goat.mired.org (tmda-ofmipd) with ESMTP; Wed, 29 Dec 2010 03:52:31 -0500 Date: Wed, 29 Dec 2010 03:52:30 -0500 To: modules-dev@httpd.apache.org Subject: Re: Doing left-over request processing at startup.... Message-ID: <20101229035230.5a8070c1@bhuda.mired.org> In-Reply-To: References: <20101228074659.74dc08ad@bhuda.mired.org> <20101228142709.39b0ed56@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.7.7 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer On Tue, 28 Dec 2010 12:37:39 -0800 Brian McQueen wrote: > What I was imaging is all requests going through that same queue and > some daemon works the queue all the time. The httpd is one interface > to the queue. So there is no such hook required. Just start up the > queue drainer and start the httpd. Spikes won't take down the site. > Its a good design. How do you get the queue to handle the normal case (I'm dealing with failure cases here), where the client sends a request to the proxy, which forwards it to the back end, gets the response, and then sends that back to the client and gets an acknowledgment? If the queue can talk to the client, then the apache proxy isn't doing anything useful, is it? If the queue can't talk to the client, then handing it a request means the request has to fail, so it should only get involved in failed requests. Which once again brings us back to the original question: some apache process died in the middle of handling a request, so it needs to be handed to the queue to reverse, and this gets discovered at apache startup time. I can certainly arrange the system to start the queue handler before apache boots, but I still need a place in the startup processing after checking the state file to hand things off to the queue. Come to think of it, I'm not sure this problem can be avoided if there's an apache module doing the work of insuring success or reversal at all: if the module dies before a request is finished (one way or the other) and apache is shut down before it's dealt with, then it's going to get found at startup time and we're back to that question. But the point of the module is to do the success/reversal handling. The current code actually works fine - except for this timing issue. If I kill apache in the middle of handling a reversal, and restart it, the first connection will cause the unfinished reversal to be finished. I'm trying to find some way to make this happen at startup, instead of on the first connection. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org