tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Koecke>
Subject Re: mod_jk in a cluster
Date Fri, 06 Apr 2001 08:54:29 GMT
James Courtney wrote:
> With the exception of failover (case 4 below), I believe that the first
> three cases can be handled by having your load balancer be "sticky" by
> client address to any of the app servers (machines running Apache with
> Tomcat).  Thus if your load balancer receives a request from client
> and round robin assigns the request to server B, given
> servers A, B, and C, then all subsequest requests from
> should be routed to server B.

Our load balancer is very poor. He does weighted round robbin and the
weights are the system load of the cluster computer. He can't look in
the IP-Packets and doesn't know anything about sessions. And he also
doesn't cache the client-ip's. So the load balancer can't handle the
stickyness of the sessions. This is handled in the past by mod_jserv in
the apache-webserver on the cluster. But now we want to use tomcat with
mod_jk because of 2.2servlets and the better handling of SSL in ajp13.
After playing around with mod_jk I build a new worker, my needs are more
like a router (because of the sessions) with failover and not a load
balancer (lb-worker). So I think my first idea to add a new property to
the lb-worker wasn't clever. mod_jk is compiled, so I have to test it.
This will take a little time.

>  If B ever goes down the session information
> from is lost and the client will have to retry their
> session.  To implement a failover system is highly non-trivial and my
> understanding is that most application servers (even commercial ones) do not
> support this.  In fact I'm told by several coworkers who worked formerly for
> BEA and know people there up to and including the B, the E, and the A that
> WebLogic only recently got failover with session replication right.  To make
> this work you will need a somewhat complicated session replication mechanism
> between all app servers which is n(n-1) replications (in this case 6) if
> replication is done between all servers and at best n choose 2 (in this case
> 3, or an extra session "write through" per request if you prefer)
> replications if each app server has a single failover server.  That can be a
> lot of network traffic and a lot of new code.  If I'm wrong and there's a
> way to make this work in Tomcat then kudos to all involved and let me know
> how to do it:)!
> -Jamey

I agree. Session replication is a solution but it isn't clever. You have
to mutch traffic for the hopefully rare case of a server crash. So we
make the following: If you have a session on a server wich is crashed,
you get a new one on a server which is up and start at the beginning.
This is handled by our servlets. So with my new worker in conjunction
with our servlets I should get the desired behaviour. Thanks to the
developers of mod_jk! My C-knowledge is not very well, but with the help
of the comments and variable/function-names in the source I got it. The
code is a little bit special to our purpose, but if there are interests
in the small code I could send it to the list. But I think we should
wait till it is tested :).

Dipl.-Inform. Bernd Koecke
Schlund+Partner AG
Fon: +49-721-91374-0

View raw message