tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Koecke ...@schlund.de>
Subject Re: PROPOSAL: mod_jk2: Group/Instance
Date Fri, 03 May 2002 15:41:47 GMT
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


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message