tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre StĂžlsvik <>
Subject RE: Tomcat clustering without Apache
Date Tue, 17 Aug 2004 09:59:26 GMT
On Mon, 16 Aug 2004, Mitchell Teixeira wrote:

| Thanks for the responses so far on this topic.  Seems like I need to
| elaborate a little....
| We are looking towards Tomcat clustering to solve a problem caused by
| so-called Megaproxy ISPs such as AOL, etc. These ISPs make it look as if
| the same client is coming from multiple IP addresses.

How nice of them..! ;)

| This breaks our app, quite simply.

I can't understand this, though. Do you sort/stick your sessions on ip??
  What about simple, commonday problems like NAT-LANs? Where 50 PCs from
the same office, company, houshold, office, whatever, seems to come from
the same IP?

You need cookies. And you need a loadbalancer that "sticks the sessions"
based on cookie. I know that "Cisco LocalDirectory" can do this, and
something called "BigIP" - both of which are cluster-boxes that uses
different style of "stickyness", the cookie-based stickyness being the
most commonly used for things with sessions.
  (Note that the LocalDirector does not need to know of the
session-semantics, timeout or anything, of the app server (Tomcat) behind.
It just needs -anything- that is unique coming from the client every time
it connects - so to keep the stickyness. Whether Tomcat chooses to drop
the cookie, doesn't really matter, as LocalDirectory simply still would
route that client to this specific box - and your app would understand it
as a new client coming in).

| We're hoping that clustering, with its replicated session data will
| resolve the problem where a customer hitting one physical server and
| adding items to the cart (and therefore session data) then goes to
| checkout and at that moment they appear to be coming from a different IP
| address and end up on the other physical server and an empty cart!

Hmm - I can't seem to imagine that solving your problem in a nice way..
Remember that replicating the session data is rather expensive - and if
your problem is performance (why would you have multiple servers in the
first place?) - then you'll now have to replicate session data between
servers on every client access in addition to your earlier bottlenecks.

| Load balancing with "stickiness" helps some, but not completely. Add SSL
| requirements to the mix and you can imagine the headache.

No, I can't seem to imagine! ;) You should let LocalDirector do the
SLL'ing - and then you can use the "SSL Session" as stickyness too.

Note that there are some open source solutions to this problem, using a
specially configured Linux box as an imitation of the LocalDirector.

Note (2) that to achieve no-single-point-of-failure, you'd need -two-
LocalDirectors - they're then linked using some super-proprietary bridge,
and all state are replicated between the two - if one fails, the other
takes over immediately, incl. the TCP connections.
  This is also copied in the open source solution - but I haven't tested
it at all.

| There are lots of load balancing and hardware accellerator vendors
| professing to have a solution, but none of these are really addressing
| the root problem.

I must be missing something - what is the root problem, exactly?

| So, with all this said, is it possible to make two or more physical
| servers talk as a Tomcat cluster without Apache or IIS, etc.?  All
| references seem to rely on Apache to make clustering happen.  (just like
| some texts on JSP rely too much on using Struts to teach JSP! <end rant>).

Just out of curiousity, why can't you use Apache in front?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message