Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PROPOSAL Tomcat 4.x] Cluster
Date: Thu, 11 Oct 2001 19:16:51 -0400
Message-ID: <08673498F568A143BB6C2B5E47CB1C7D457456@USMAIL1.rfish.com>
Thread-Topic: [PROPOSAL Tomcat 4.x] Cluster
Thread-Index: AcFSoT99Af6E2W18Qla15GTZB2zucgAB39PQ
From: "Bip Thelin" <Bip.Thelin@razorfish.com>
To: <tomcat-dev@jakarta.apache.org>

> -----Original Message-----
> From: Gomez Henri [mailto:hgomez@slib.fr]=20
>=20
> 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 ?
>=20
> It will help recover from a TC crash when using farm of TC=20
> (in load-balancing or fault-tolerant mode) .
>=20
> For example :
>=20
> Apache server use mod_jk and balance load between TC1, TC2, TC3.
>=20
> After a session creation TC1 send both http anwser +=20
> serialized session
> data to Apache. When session is updated, TC1 resend session datas.
>=20
> TC1 crash and then Apache resend the request to TC2 + the previously
> saved session stuff.
>=20
> And it won't need to deploy multicast stuff.
>=20
> ajp14 could be extended in such a way.
>=20
> 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.

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.

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.


	Bip Thelin