Hi Costin, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
