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? Endre --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
