I'm trying to create different instances of Tomcat similar to what my
ISP has.  I think they have an Apache front-end and each user gets their
own instance of Tomcat and JVM.  I want to setup this same thing for a
client I have - and I *hope* to make it run on OS X, Windows (2000/XP)
and Linux (Red Hat 7.3).  Linux is their production platform.

I read this article (http://www.ubeans.com/tomcat/) which details how to
do it with the AJP connector.  I think I read that the WARP connector is
not supported on Windows - is this true?  What do you veterans
recommend?  We've got a fresh server and our application works across
all 4.x versions of Tomcat, so I'd like to use the latest stuff.

Some interesting stuff from the article:
----------------------------------------
Question 1:
Why did you choose to use the AJP13 connector rather than the WARP
connector that is recommended? 

Answer:
The warp connector is used in conjunction with mod_webapp, and
mod_webapp does not currently support load balancing. 

Also, I found the documentation for the warp connector on the Jakarta
web site to be quite lacking. See:
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/warp.html 

I know that the future lies in the warp connector, but in the meantime,
I needed something. The documentation did not explain to me exactly what
benefits I would get from using the Warp connector as opposed to AJP13. 

Question 2:
You might specify that creating two instances of the tomcat installation
is not needed as you can share the main binaries and libs by specifying
2 distinct CATALINA_BASE variables. 

True, but in real life the two tomcat servers are usually located on two
different machines. My setup might be overkill for a single machine
setup, but it's easy to tar up the "tomcat2" server and put it on a
second machine; you just have to change "localhost" to the appropriate
machine name in /usr/local/apache/conf/workers.properties and you're
done. 

Question 3:
What does not work and what does work in load balancing? 

Answer:
Load balancing works great. 

1. Session affinity works
Which means that when a client browser is directed to a Tomcat server by
the load balancer, then future queries from that same browser session
will always be directed to the same tomcat server. This is important
because sessions that are created in a specific tomcat server, say
"tomcat1", do not exist in the other server "tomcat2", and thus if the
client was directed to another tomcat server than the one where his
session is stored, then all his session data would be lost. 

Some people are working on sessions that will be replicated across all
tomcat servers in the cluster, so I'll just wait for it to become
available rather than make a homebrewed distributed session mechanism. 

The downside of not having sessions replicated across all the tomcat
servers in the cluster is that if one tomcat server dies, all the
sessions that it contained are lost, which usually makes a lot of
unhappy users. 

2. Failover works
If one tomcat server dies, the load balancer then "rebalances" the
queries to the remaining tomcat servers. 

3. Failback works
When a tomcat server comes back from the dead, the load balancer
automatically starts to send queries to it. So you can actually add
capacity to your cluster on the fly. 

4. Weighted load balancing works
In /usr/local/apache/conf/workers.properties, I assigned a load
balancing factor of 100 to both "tomcat1" and "tomcat2" servers. Then I
changed the lbfactor of "tomcat1" to 101, and I saw that effectively the
"tomcat1" server received more load than the "tomcat2" server, which is
something you want when for example your "tomcat1" server is a
faster/newer machine while your "tomcat2" server is a slower machine
which cannnot take as much load as the other one. 



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to