Henri,

This is actually very easy with the existing code and a tiny patch I
submitted a few weeks ago.  We're using it in production mode, so it is
known to be stable.  The first version I submitted had some additional
logging added, but I'm attaching a minimal patch.

All you have to do is set the lbfactor in workers.properties to 0, and
it should never select that worker unless the session route points to
it, or the primary worker is down.

This also has the added benefit of making externally load balanced
clusters behave properly for AOL/Compuserve users without special
configuration of the load balancer.  Those services use IP randomizing
proxies which break generic IP-based sticky.  This will cause the
sessions to be re-routed from the Apache that receives the request to
the Tomcat that initiated the session.  This actually works, because we
were able to remove all of our special configurations to deal with this
from our load balancers.  The problem is described at
http://webmaster.info.aol.com/index.cfm?article=15

This patch changes the behavior by pre-initializing lb_value for each
worker.  The selection algorithm searches for the worker with the lowest
lb_value that is not in a failed state.  It then increments the lb_value
by the lb_factor.  lb_factor is set to the inverse (1/x) of the
lb_factor specified in the config file.  When lb_factor in the config
file is 0, this number becomes basically MAX_DOUBLE.  That means that
lb_value becomes MAX_DOUBLE, so it will never be selected for any
practical purposes.

This patch has been tested extensivly in production use, and works
perfectly.

Paul Frieden




GOMEZ Henri wrote:
> 
> >On Thu, Jun 14, 2001 at 10:28:47AM +0200, GOMEZ Henri wrote:
> >> mod_jk support Apache 2.0
> >>
> >> And TC 4.0 as preliminary support for ajp13 used
> >> in mod_jk.
> >>
> >> Could you take a look at it ?
> >
> >Okay, what's the difference between mod_webapp and mod_jk?  I thought
> >that mod_webapp was the preferred TC 4.0 connector?  This seems like
> >this is worthy of a FAQ.  We've still got people using mod_jserv...
> 
> One of the goal of j-t-c, is to be the answer to :
> 
> 'how to connect my webserver to tomcat ?'
> 
> A great effort has been deployed in having an easy to use
> build stuff.
> Next effort will be documentation and ........... lobbying :)
> 
> >Oh, is it that mod_webapp uses the Warp protocol, not ajp13?  Does
> >ajp13 support the TC 4.0 hot-deploy functionality?  -- justin
> 
> not in ajp13. But it's successor ajp14, have a strongest login
> procedure, and autoconf support (uri handled passed to web-server).
> Also planned is to inform the web-server of context state, ie
> when a context is put down (for admin purpose), the web-servlet
> must learn it and route request to another servlet-engine (if we
> are in load-balancing configuration).
> 
> what make me think we should add a fault-tolerant/backup-mode worker
> in mod_jk. A la load-balancing, having a group of worker (servlet engine),
> with one principal, and many as backup. If the principal could no more
> handle a request (failure or context down), just have the request
> routed to next worker in list.
> 
> What about ?
--- jk_lb_worker.orig   Fri Jun 15 10:23:42 2001
+++ jk_lb_worker.c      Fri Jun 15 10:23:54 2001
@@ -426,7 +426,7 @@
                 p->lb_workers[i].lb_factor = jk_get_lb_factor(props, 
                                                                worker_names[i]);
                 p->lb_workers[i].lb_factor = 1/p->lb_workers[i].lb_factor;
-                p->lb_workers[i].lb_value = 0.0;
+                p->lb_workers[i].lb_value = p->lb_workers[i].lb_factor;
                 p->lb_workers[i].in_error_state = JK_FALSE;
                 p->lb_workers[i].in_recovering  = JK_FALSE;
                 if(!wc_create_worker(p->lb_workers[i].name, 

Reply via email to