[PATCH] added handling of a main worker in jk_lb_worker, Re: PROPOSAL: mod_jk2: Group/Instance

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

Hi Costin,

it wasn't difficult, so here is the new patch. The new (old) behavior is:
The main worker is defined by a lb_value of 0. This will never be changed in 
jk_lb_worker. The other workers can get a value greater than 0. If the value 
from config file is less than 0 it is multiplicated with -1.

Your are right this is a better solution. We can switch from doubles to int and 
we get the other worker balanced if the main worker is down.

Bernd

Bernd Koecke wrote:
> Hi Costin,
> 
> costinm@covalent.net wrote:
> 
>> Hi Bernd,
>>
>> First, many thanks for your help :-)
>>
>>
> 
> your welcome, its a lot of fun :)
> 
>>> No, I think not :). I checked it yesterday. With some additional log 
>>> statements in the validate function of jk_lb_worker.c you get the 
>>> value _inf_ for the lb_factor and lb_value (line 434-444). Because if 
>>> it would be set to 1, my config hadn't worked. Because I set the 
>>> local worker to 1 and the others to 0.
>>
>>
>>
>> I'll check again, and fix it if necesarry.
>>
>> I wrote some code in jk2 that seems to solve the problem, and I can
>> backport this to jk1 if it is correct.
>>
>> Probably this is my mistake - I remember the discussion and the patch
>> that was sent for this problem, and most likely I did something
>> wrong commiting it ( i.e. I did few changes trying to simplify it, and it
>> seems I 'simplified' too much ). But my memory still has the patch's 
>> logic
>> which seemed fine :-)
>>
>>
>>> This is possible, but then you must add a check if the value is 0. 
>>> Because without it you calc 1/0 with an int and this will give you an 
>>> error.
>>
>>
>>
>> Yes, of course. 0 will continue to mean 'default worker'.
>>
> 
> see below
> 
>> I'm not very comfortable with float calculations in the critical
>> path ( and in an area that is executed concurently !). The only problem
>> is what happens on overflows - the lb_value may become 0 ( or a small 
>> value ) and then the worker will take all the load.
>>
>>
>>> Thats not the whole story. Its right you will check the main worker 
>>> when its back again and use it only once. Because when the request 
>>> was successful handled rec->in_recovering is true (line 332 of 
>>> jk_lb_worker.c, service function). Than get_max_lb get the value 
>>> _inf_ from one of the other worker. Than the things happen which I 
>>> said in my prior mail.
>>
>>
>>
>>> That was it what I did in my sent patch, the additional documentation 
>>> was sent a few days later. But my additions to the lb_worker were a 
>>> little bit to complex. You are right we should get it when we use the 
>>> flag only on the main worker and change the behavior after a failure 
>>> for this worker. But we need the trick with 0/inf for the other 
>>> worker, because only with this we have the situation that the other 
>>> worker wouldn't be asked when there is no session and the main worker 
>>> is up.
>>
>>
>>
>>
>> Ok, can you send the patch again :-) ?
>> For going back to the main worker - if we let it with lb_value=0 at all
>> time ( i.e. we don't alter that at any time ), and only in_error_state 
>> is set on failure - then I believe the thing will work fine.
>>
>>
> 
> Thats the invers from the actual situation. So my patch from a few hours 
> earlier this day depends on the fact that the other worker get a 
> lb_value of 0 in the config file. This will be converted to _inf_ and 
> the main worker gets 1 and this  will be the minimal lb_value of the 
> balanced workers. If we want the possibility to switch to ints I could 
> send a new patch which handles 0 as a special value for the main worker.
> 
> Should I?
> 
> Bernd
> 
> 
>>
>>> I will try to build another patch and send it. I think it could be 
>>> possible without an additional flag.
>>
>>
>>
>> Great !
>>
>>
>>
>>> Another tought about this:
>>> When you use double and we fix the handling after an error, the main 
>>> worker would never reach _inf_. Because the lb_factor is < 1 if 
>>> lb_value wasn't 0. After choosing the worker this value is added to 
>>> the lb_value. But with a high value for lb_value the differenc 
>>> between two savable double numbers is greater than the lb_factor. But 
>>> this is only interessting in theory. I think in real world we will 
>>> reboot apache before this will happen :).
>>
>>
>>  
>> That may become a problem if we use ints.
>>
>> Costin
>>
>>
>>
> [...]
> 
> 



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

Re: [PATCH] added handling of a main worker in jk_lb_worker, Re: PROPOSAL: mod_jk2: Group/Instance

[co...@covalent.net]

Done. 

BTW, you may have an older version - you should update from head
and then test.

Thanks.

Costin

On Fri, 3 May 2002, Bernd Koecke wrote:

> Hi Costin,
> 
> it wasn't difficult, so here is the new patch. The new (old) behavior is:
> The main worker is defined by a lb_value of 0. This will never be changed in 
> jk_lb_worker. The other workers can get a value greater than 0. If the value 
> from config file is less than 0 it is multiplicated with -1.
> 
> Your are right this is a better solution. We can switch from doubles to int and 
> we get the other worker balanced if the main worker is down.
> 
> Bernd
> 
> Bernd Koecke wrote:
> > Hi Costin,
> > 
> > costinm@covalent.net wrote:
> > 
> >> Hi Bernd,
> >>
> >> First, many thanks for your help :-)
> >>
> >>
> > 
> > your welcome, its a lot of fun :)
> > 
> >>> No, I think not :). I checked it yesterday. With some additional log 
> >>> statements in the validate function of jk_lb_worker.c you get the 
> >>> value _inf_ for the lb_factor and lb_value (line 434-444). Because if 
> >>> it would be set to 1, my config hadn't worked. Because I set the 
> >>> local worker to 1 and the others to 0.
> >>
> >>
> >>
> >> I'll check again, and fix it if necesarry.
> >>
> >> I wrote some code in jk2 that seems to solve the problem, and I can
> >> backport this to jk1 if it is correct.
> >>
> >> Probably this is my mistake - I remember the discussion and the patch
> >> that was sent for this problem, and most likely I did something
> >> wrong commiting it ( i.e. I did few changes trying to simplify it, and it
> >> seems I 'simplified' too much ). But my memory still has the patch's 
> >> logic
> >> which seemed fine :-)
> >>
> >>
> >>> This is possible, but then you must add a check if the value is 0. 
> >>> Because without it you calc 1/0 with an int and this will give you an 
> >>> error.
> >>
> >>
> >>
> >> Yes, of course. 0 will continue to mean 'default worker'.
> >>
> > 
> > see below
> > 
> >> I'm not very comfortable with float calculations in the critical
> >> path ( and in an area that is executed concurently !). The only problem
> >> is what happens on overflows - the lb_value may become 0 ( or a small 
> >> value ) and then the worker will take all the load.
> >>
> >>
> >>> Thats not the whole story. Its right you will check the main worker 
> >>> when its back again and use it only once. Because when the request 
> >>> was successful handled rec->in_recovering is true (line 332 of 
> >>> jk_lb_worker.c, service function). Than get_max_lb get the value 
> >>> _inf_ from one of the other worker. Than the things happen which I 
> >>> said in my prior mail.
> >>
> >>
> >>
> >>> That was it what I did in my sent patch, the additional documentation 
> >>> was sent a few days later. But my additions to the lb_worker were a 
> >>> little bit to complex. You are right we should get it when we use the 
> >>> flag only on the main worker and change the behavior after a failure 
> >>> for this worker. But we need the trick with 0/inf for the other 
> >>> worker, because only with this we have the situation that the other 
> >>> worker wouldn't be asked when there is no session and the main worker 
> >>> is up.
> >>
> >>
> >>
> >>
> >> Ok, can you send the patch again :-) ?
> >> For going back to the main worker - if we let it with lb_value=0 at all
> >> time ( i.e. we don't alter that at any time ), and only in_error_state 
> >> is set on failure - then I believe the thing will work fine.
> >>
> >>
> > 
> > Thats the invers from the actual situation. So my patch from a few hours 
> > earlier this day depends on the fact that the other worker get a 
> > lb_value of 0 in the config file. This will be converted to _inf_ and 
> > the main worker gets 1 and this  will be the minimal lb_value of the 
> > balanced workers. If we want the possibility to switch to ints I could 
> > send a new patch which handles 0 as a special value for the main worker.
> > 
> > Should I?
> > 
> > Bernd
> > 
> > 
> >>
> >>> I will try to build another patch and send it. I think it could be 
> >>> possible without an additional flag.
> >>
> >>
> >>
> >> Great !
> >>
> >>
> >>
> >>> Another tought about this:
> >>> When you use double and we fix the handling after an error, the main 
> >>> worker would never reach _inf_. Because the lb_factor is < 1 if 
> >>> lb_value wasn't 0. After choosing the worker this value is added to 
> >>> the lb_value. But with a high value for lb_value the differenc 
> >>> between two savable double numbers is greater than the lb_factor. But 
> >>> this is only interessting in theory. I think in real world we will 
> >>> reboot apache before this will happen :).
> >>
> >>
> >>  
> >> That may become a problem if we use ints.
> >>
> >> Costin
> >>
> >>
> >>
> > [...]
> > 
> > 
> 
> 
> 
> 


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