Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 55204 invoked from network); 14 Feb 2008 13:05:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Feb 2008 13:05:24 -0000 Received: (qmail 58213 invoked by uid 500); 14 Feb 2008 13:05:18 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 57351 invoked by uid 500); 14 Feb 2008 13:05:16 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 57338 invoked by uid 99); 14 Feb 2008 13:05:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2008 05:05:16 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [209.133.199.10] (HELO jimsys.jaguNET.com) (209.133.199.10) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2008 13:04:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by jimsys.jaguNET.com (Postfix) with ESMTP id 859296FE223 for ; Thu, 14 Feb 2008 08:04:52 -0500 (EST) Message-Id: <8A6C9933-F9E8-4814-A792-01E31D456930@jaguNET.com> From: Jim Jagielski To: dev@httpd.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ping for http in mod_proxy Date: Thu, 14 Feb 2008 08:04:52 -0500 References: X-Mailer: Apple Mail (2.919.2) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 14, 2008, at 6:33 AM, Akins, Brian wrote: > On 2/13/08 12:50 PM, "Jim Jagielski" wrote: >> That was the other option as well... some sort of hearbeat >> loop which updates worker status. Still, we get into the issue >> with how much of "how proxy connects to and communicates with >> the backend" to honor or work around. > > An external process (using serf maybe) would be easy. Just have > some of the > worker stats in shared memory. The healthchecker writes status to > it, and > httpd reads from it. > Yep... the process would fork off at Apache start time and update it's own current health as well as update its own knowledge of the health of the external backends... Not convinced that multicasting is right for this due to the types of architectures web servers usually find themselves in :)