tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre StĂžlsvik <En...@Stolsvik.com>
Subject Re: [PROPOSAL Tomcat 4.x] Cluster
Date Fri, 12 Oct 2001 08:06:05 GMT
On Thu, 11 Oct 2001, Bip Thelin wrote:

| > -----Original Message-----
| > From: Gomez Henri [mailto:hgomez@slib.fr]
| >
| > Did you ever have considered using the web connector, mod_jk for
| > example, to forward serialized stuff from TC to web-server, when
| > needed, at answer time ?
| >
| > It will help recover from a TC crash when using farm of TC
| > (in load-balancing or fault-tolerant mode) .
| >
| > For example :
| >
| > Apache server use mod_jk and balance load between TC1, TC2, TC3.
| >
| > After a session creation TC1 send both http anwser +
| > serialized session
| > data to Apache. When session is updated, TC1 resend session datas.
| >
| > TC1 crash and then Apache resend the request to TC2 + the previously
| > saved session stuff.
| >
| > And it won't need to deploy multicast stuff.
| >
| > ajp14 could be extended in such a way.
| >
| > What do you think of that ?
|
| It's an interesting idea, I do believe we would need the connectors
| and/or a module for TC that does URL/Session rewriting to hide the
| different machines in the cluster. Is this already implemented in JK
| or have I dreamt that?
|
| Anyway, in your example above you're mentioning 1*httpd and n*TC, if
| we have 1 Apache being the "session hub" we would have a singlepoint
| of failure which would be as bad as not using clustering at all. I guess
| you mean that one shoule also run n*httpd also and cluster the sessions
| in between them, with multicast or other technology of choice.

I think that Gomez' idea was pretty cool. There is a couple of points
here, I think. I can't be bothered to write it into a complete argument,
so I'll just state my points of view:

*) Java is slowish.

*) C is fastish.

*) The "appserver" would most probably have a rather heavy, advanced
system running on it, maybe CPU, IO and everything-intesive.

*) The loadbalancer would most probably be a smallish, easily overviewd
system, where everthing is about passing on requests (and also possibly
keep a serialized version of the sessions in the system), which doesn't
require much of anything.

*) A heavy, advanced system is more likely to go down than a small,
easily overviewed system.

*) For very many systems, the extreme failover part of this idea is not
_that_ important. For these systems the _distribution_ part is much more
interesting, along with reasonable failover capabilities

A system with 1 rather heavy-duty (but could still be PC based)
loadbalancer (apache + mod_jk or whatever, C code) and many Tomcats
running on anything would be totally OK for these systems. If the apache
loadbalancing thing goes down, then you are definately screwed, but just
make sure it doesn't! One could then be a bit more "sloppy" with (all) the
Java code, because those servers could go up and down as much as they
pleased, and the apache thing would redirect the next response to a tomcat
that's up.

One thing to remeber is that IF a request isn't actually finished (the
tomcat that got the request crashes or locks up midway), the next tomcat
that gets the request should be notified in some way of this. This because
some transaction-style operation could easily be half-finished, and
thereby leave the session in the loadbalancer in a wrong state, since it
hasn't gotten the half-way updated session.

( There is just too many problems!! ;)

|
| Why I started to go down the multicast-road was because I was looking
| at how Weblogic had solved the issue, my first plan was not to make it
| as a complete package as Weblogics but somewhere in that direction
| anyway.

The multicast road DO have a _whole_ _load_ of issues. Total replication,
where every tomcat have every session, is rather IO and CPU intesive. If
there are 5000 sessions (requiring a bunch of tomcats), all these 5000
session would be replcated through all those tomcats. You could easily end
up in only replicating sessions, having no CPU left for actually doing
anything!
  Or you could of course partition the set of servers, but then both the
mod_jk and the replication system would get rather advanced and error
prone. A whole bunch of issues must be solved..

|
| I also had some plans on building support for deploying a webapp that
| then would get replicated and deployed to every TC in the cluster.

Everything sounds _very_ cool! How's things coming along?


-- 
Mvh,
Endre


Mime
View raw message