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