low hanging fruit in proxy_balancer

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

One of our class attendees this week had an interesting suggesting for
a balancer-manager feature.  Right now each member is a 2-state, either
enabled or disabled.

For session stickiness, he suggested a tristate third option to bleed
out the remaining sessions, dispatching no /new/ sessions into the
particular member.  This would let the existing sessions drain and
complete, in order to take down a member without disrupting any logins.

Of course my plate is entirely full for several months, so I'm just
tossing it out to balancer fans to see if anyone shares his itch.

Bill

Re: low hanging fruit in proxy_balancer

[Mladen Turk <mt...@apache.org>]

Jim Jagielski wrote:
> 
> On Apr 17, 2008, at 8:56 AM, Plüm, Rüdiger, VF-Group wrote:
>>
> 
> Yeah, but we *should* differentiate between the 2. There are (well,
> should be) administrative status and "runtime" status.
>

It worked initially, but someone added PROXY_WORKER_STOPPED to
PROXY_WORKER_IS_USABLE, which should be fine, but ONLY if there
is no session route in the request (eg. new request)

Regards
--
(TM)

Re: low hanging fruit in proxy_balancer

[Jim Jagielski <ji...@jaguNET.com>]

On Apr 17, 2008, at 8:56 AM, Plüm, Rüdiger, VF-Group wrote:
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: William A. Rowe, Jr.
>> Gesendet: Donnerstag, 17. April 2008 14:49
>> An: dev@httpd.apache.org
>> Betreff: low hanging fruit in proxy_balancer
>>
>> One of our class attendees this week had an interesting suggesting  
>> for
>> a balancer-manager feature.  Right now each member is a
>> 2-state, either
>> enabled or disabled.
>>
>> For session stickiness, he suggested a tristate third option to bleed
>> out the remaining sessions, dispatching no /new/ sessions into the
>> particular member.  This would let the existing sessions drain and
>> complete, in order to take down a member without disrupting
>> any logins.
>
> In principle we already have this, but we do not make any difference  
> between
> PROXY_WORKER_DISABLED and PROXY_WORKER_STOPPED and of course we are  
> are missing
> the needed field in the balancer manager of course to switch between  
> enabled,
> disabled and stopped.
>

Yeah, but we *should* differentiate between the 2. There are (well,
should be) administrative status and "runtime" status.

Re: low hanging fruit in proxy_balancer

[Plüm, Rüdiger, VF-Group <ru...@vodafone.com>]

 

> -----Ursprüngliche Nachricht-----
> Von: William A. Rowe, Jr.
> Gesendet: Donnerstag, 17. April 2008 14:49
> An: dev@httpd.apache.org
> Betreff: low hanging fruit in proxy_balancer
> 
> One of our class attendees this week had an interesting suggesting for
> a balancer-manager feature.  Right now each member is a 
> 2-state, either
> enabled or disabled.
> 
> For session stickiness, he suggested a tristate third option to bleed
> out the remaining sessions, dispatching no /new/ sessions into the
> particular member.  This would let the existing sessions drain and
> complete, in order to take down a member without disrupting 
> any logins.

In principle we already have this, but we do not make any difference between
PROXY_WORKER_DISABLED and PROXY_WORKER_STOPPED and of course we are are missing
the needed field in the balancer manager of course to switch between enabled,
disabled and stopped.

Regards

Rüdiger

Re: low hanging fruit in proxy_balancer

[Jim Jagielski <ji...@jaguNET.com>]

On Apr 17, 2008, at 8:49 AM, William A. Rowe, Jr. wrote:
> One of our class attendees this week had an interesting suggesting for
> a balancer-manager feature.  Right now each member is a 2-state,  
> either
> enabled or disabled.
>
> For session stickiness, he suggested a tristate third option to bleed
> out the remaining sessions, dispatching no /new/ sessions into the
> particular member.  This would let the existing sessions drain and
> complete, in order to take down a member without disrupting any  
> logins.
>
> Of course my plate is entirely full for several months, so I'm just
> tossing it out to balancer fans to see if anyone shares his itch.
>

This isn't the 1st time this has been suggested... Having a
'On/Off/Taking-offline' state engine.