Return-Path: 
 <dev-return-54363-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: (qmail 13471 invoked from network); 31 Jul 2006 16:22:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 31 Jul 2006 16:22:07 -0000
Received: (qmail 82158 invoked by uid 500); 31 Jul 2006 16:22:04 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 82104 invoked by uid 500); 31 Jul 2006 16:22:03 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 82093 invoked by uid 99); 31 Jul 2006 16:22:03 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 09:22:03 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [207.113.241.148] (HELO iss04.interliant.com) (207.113.241.148)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 09:22:02 -0700
Received: from EX-008.mail.navisite.com (ex-008.interliant.com
 [207.113.240.188])
	by iss04.interliant.com (8.10.2/8.10.2) with ESMTP id k6VGR3X17015
	for <dev@httpd.apache.org>; Mon, 31 Jul 2006 11:27:08 -0500 (CDT)
Received: from [192.168.0.168] ([213.202.110.57]) by EX-008.mail.navisite.com
 with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 31 Jul 2006 11:21:34 -0500
Message-ID: <44CE2E08.2010705@apache.org>
Date: Mon, 31 Jul 2006 18:21:28 +0200
From: Mladen Turk <mturk@apache.org>
User-Agent: Mozilla
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: load balancer "cluster" set
References: <65FEF6CD-73FC-4427-9940-D552FB458688@jaguNET.com>
In-Reply-To: <65FEF6CD-73FC-4427-9940-D552FB458688@jaguNET.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Jul 2006 16:21:34.0286 (UTC)
 FILETIME=[63CD5EE0:01C6B4BD]
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Jim Jagielski wrote:
> I'm trying to figure out which impl of the the
> LB cluster set makes the most sense and would appreciate
> the feedback.
> 
> Basically, I see 2 different methods:
> 
>    1. Members in all cluster sets which have the same or
>       lower set numbers are checked
> 
>    2. Only members is a specific set number are checked. If
>       none are usable, skip to the next cluster set.
> 
> In other words, lets assume members a, b and c are in
> set 0 and d, e and f are in set 1 and g, h and i are in
> set 2. We check a, b and c and they are not usable, so
> we now start checking set 1. Should we re-check the
> members in set 0 (maybe they are usable now) or
> just check members of set 1 (logically, the question
> is whether we doing a <= set# or == set#). I have
> both methods coded and am flip-flopping on which
> makes the most sense. I'm leaning towards #1 (<=set#).
> 
> Comments?
>

Something I planned to implement:

<Proxy balancer://clusterName#groupRoute1>
    BalancerMember .. 1.1
    BalancerMember .. 1.2
</Proxy>
<Proxy balancer://clusterName#groupRoute2>
    BalancerMember .. 2.1
    BalancerMember .. 2.2
</Proxy>
<Proxy balancer://clusterName#groupRoute3>
    BalancerMember .. 3.1
    BalancerMember .. 3.2
</Proxy>

In case you have session stickyness, where
jvmRoute is equal for all group members and
all members from groupRoute1 fails, the
groupRoute1 will always be favored depending
on the retry timeout. Now if all members from
groupRoute2 fails, the next election will still
first try to check the corresponding sticky
route members (if they are ready for retry).

So, if you always first try the corresponding
members of the session route balancer, you will
always favor them over the others.
Think this is close to your #1.

Next step is to add the shared memory slot for
balancer, so it can be dynamically maintained.

--
Mladen.