tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Koecke ...@schlund.de>
Subject [PATCH] added handling of a main worker in jk_lb_worker, Re: PROPOSAL: mod_jk2: Group/Instance
Date Fri, 03 May 2002 17:19:30 GMT
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

Mime
View raw message