PROPOSAL: mod_jk2: new lb values

[co...@covalent.net]

Based on the previous discussion:

- change lbfactor from float to int ( maybe rename it to avoid confusion)

- The value will be from 1 to MAX ( 100 ? ).

- Smaller values will mean more work. The value '0' ( or a special 
flag ? ) will mean the worker will be used allways ( as long as it is not 
in_error state ). We can make sure the '0' is the first in the list, 
and avoid looking for others.

-  A factor 2 will take 2 times fewer requests than factor 1, 3 will be 
1/3, etc. ( each worker uses a counter, and the counter is incremented on 
each request with the factor value - that's how it works today to 
implement the round roubin ).

-  When a worker reaches MAX, all workers will be reset to their
original values and error state reset. ( that means we'll reset the
error state based on number of requests, not time ) ( is this a good idea ?) 

- A value of MAX ( Or flag ? ) will mean the worker will take no 
request, except those with a previous session id. That's the gracefull
shutdown.

In addition, I'm in process of moving the lb properties to channel, 
since that's what the user should configure in jk2. 

Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: PROPOSAL: mod_jk2: new lb values

[Bernd Koecke <bk...@schlund.de>]

costinm@covalent.net wrote:
> Based on the previous discussion:
> 
> - change lbfactor from float to int ( maybe rename it to avoid confusion)
> 

It would be less magic but you have to check if the value is 0.

> - The value will be from 1 to MAX ( 100 ? ).
> 
> - Smaller values will mean more work. The value '0' ( or a special 
> flag ? ) will mean the worker will be used allways ( as long as it is not 
> in_error state ). We can make sure the '0' is the first in the list, 
> and avoid looking for others.
> 
> -  A factor 2 will take 2 times fewer requests than factor 1, 3 will be 
> 1/3, etc. ( each worker uses a counter, and the counter is incremented on 
> each request with the factor value - that's how it works today to 
> implement the round roubin ).
> 
> -  When a worker reaches MAX, all workers will be reset to their
> original values and error state reset. ( that means we'll reset the
> error state based on number of requests, not time ) ( is this a good idea ?) 
> 
> - A value of MAX ( Or flag ? ) will mean the worker will take no 
> request, except those with a previous session id. That's the gracefull
> shutdown.
> 
> In addition, I'm in process of moving the lb properties to channel, 
> since that's what the user should configure in jk2. 
> 
> Costin

I think this is a mutch better aproach then the magic zero lb_value :). I could 
check it for jk1 and I hope I get time to look deeper in jk2 to test it there too.

Bernd
-- 
Dipl.-Inform. Bernd Koecke
UNIX-Entwicklung
Schlund+Partner AG
Fon: +49-721-91374-0
E-Mail: bk@schlund.de


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

AW: PROPOSAL: mod_jk2: new lb values

[Hans Schmid <Ha...@einsurance.de>]

> -----Ursprungliche Nachricht-----
> Von: costinm@covalent.net [mailto:costinm@covalent.net]
> Gesendet: Donnerstag, 2. Mai 2002 20:15
> An: Tomcat Developers List
> Betreff: PROPOSAL: mod_jk2: new lb values
>
>
> Based on the previous discussion:
>
> - change lbfactor from float to int ( maybe rename it to avoid confusion)

Int is definately the way to go for lbfactor.

>
> - The value will be from 1 to MAX ( 100 ? ).
>
> - Smaller values will mean more work. The value '0' ( or a special
> flag ? ) will mean the worker will be used allways ( as long as it is not
> in_error state ). We can make sure the '0' is the first in the list,
> and avoid looking for others.

OK, I would do it the other way around (greater value = more work)
but this is a matter of taste.

>
> -  A factor 2 will take 2 times fewer requests than factor 1, 3 will be
> 1/3, etc. ( each worker uses a counter, and the counter is incremented on
> each request with the factor value - that's how it works today to
> implement the round roubin ).
>

OK

> -  When a worker reaches MAX, all workers will be reset to their
> original values and error state reset. ( that means we'll reset the
> error state based on number of requests, not time ) ( is this a
> good idea ?)
>
> - A value of MAX ( Or flag ? ) will mean the worker will take no
> request, except those with a previous session id. That's the gracefull
> shutdown.

I would seperate the active/inactive state (the manually set inactivity not
the one resulting from error states) from the lbfactor value
(see my other reply about the 'active' flag')

So only apply the round robin logic to channels with active=1

Note: This Active flag would be configured at runtime.
-> Mark one Tomcat to shutdown graceful means set active=0
-> Startup Tomcat would set active=1 and use the assigned lbfactor

This way you know what to do with a worker that has reached MAX
either
- it's counter has to be reset if active = 1
or
- it must stay at MAX, because it was deactivated (set to active=0)



Hans

>
> In addition, I'm in process of moving the lb properties to channel,
> since that's what the user should configure in jk2.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>