tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angus Mezick" <amez...@guidestar.org>
Subject RE: I think lb_factor in JK2 is broken (or just backwards from JK)
Date Fri, 09 Apr 2004 15:47:32 GMT
So, the only relationship between JK lbfactor and JK2 lb_factor is in
their names and the fact they have SOMETHING to do with load balancing.
They definetly don't seem to do the same thing. 
--Angus

> -----Original Message-----
> From: Henri Gomez [mailto:hgomez@apache.org] 
> 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: tomcat-dev@jakarta.apache.org
> >>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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 

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


Mime
View raw message