I am trying to figure out this JK2 load balancing code and fix the docs. I need some help verifying some of the coding decisions that have been made.
Ok, as I dig deeper into the code, I discover the following: Both worker:AJP13 and channel.socket can have both the level and lb_factor parameters The docs only mention channel.socket having lb_factor The docs only mention worker:AJP13 having level What is the prefered way to assign these attributes? What happens if I reverse them, group both to one section, or put both parameters in both sections? Level: the lower the level the higher your priority. If I give channel/socket pair A level 1 and pair B level 2, then pair A will get ALL the traffic unless it is down. True or False? If False, why? Lb_factor: The lower the lb_factor the more traffic you get. If channel/socket pair A has a factor of 1, pair B has a factor of 3 and pair C has a factor of 6 the traffic will be assigned thus: AAABAAABC.... True or False? If False, why? Thanks for any and all help that can be provided. --Angus > -----Original Message----- > From: Henri Gomez [mailto:[EMAIL PROTECTED] > Sent: Friday, April 09, 2004 11:02 AM > To: Tomcat Developers List > Subject: Re: I think lb_factor in JK2 is broken (or just > backwards from JK) > > > Angus Mezick wrote: > > > I forgot to mention that I am using the following software: > > Apache: apache_2.0.47-win32-x86-no_ssl.msi > > JK2: mod_jk2-2.0.43.dll AND the 2.0.4 mod_jk.so from the > jakarta site. > > Tomcat: 4.1.27 > > > > > >>-----Original Message----- > >>From: Angus Mezick > >>Sent: Thursday, April 08, 2004 9:44 AM > >>To: [EMAIL PROTECTED] > >>Subject: I think lb_factor in JK2 is broken (or just > >>backwards from JK) > >> > >> > >>Web01 is running apache > >>Web01 and web02 are running tomcat > >>I set web01 to lb_factor=1 > >>I set web02 to lb_factor=15 > > From what I see in code, lb_factor is used as increment and not as > load factor... > > if (rc != NULL) { > /* It it's the default, it'll remain the default - we don't > increase the factor > */ > rc->in_error_state = JK_FALSE; > if (rc->lb_value != 0) { > int newValue = rc->lb_value + rc->lb_factor; > > if (newValue > 255) { > rc->lb_value = rc->lb_factor; > /* Roll over. This has 2 goals: > - avoid the lb factor becoming too big, > and give a > chance to run to > workers that were in error state ( I think it's > cleaner than looking for "max" ) > - the actual lb_value will be 1 byte. Even on the > craziest platform, that > will be an atomic write. We do a lot of > operations > on lb_value in a MT environment, > and the chance of reading something > inconsistent is > considerable. Since APR > will not support atomic - and adding a CS > would cost > too much, this is actually > a good solution. > > Note that lb_value is not used for > anything critical > - just to balance the load, > the worst that may happen is having a worker stay > idle for 255 requests. > */ > for (i = 0; i < lb->workerCnt[currentLevel]; i++) { > jk_worker_t *w = > lb->workerTables[currentLevel][i]; > w->lb_value = w->lb_factor; > } > } > else { > rc->lb_value = newValue; > } > } > } > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
