RE: fault-tolerant/backup_mode in mod_jk : Was: [j-t-c] OS poll = [j-t-c] webserver poll

2001-06-18 Thread GOMEZ 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.

Exactly what we want :)

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.

Seems fine to me. I'll commit it today :)



Re: fault-tolerant/backup_mode in mod_jk : Was: [j-t-c] OS poll = [j-t-c] webserver poll

2001-06-15 Thread Paul Frieden

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, 



fault-tolerant/backup_mode in mod_jk : Was: [j-t-c] OS poll = [j-t-c] webserver poll

2001-06-14 Thread GOMEZ Henri

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 ?