>As for how often the sessions are updated, I >don't know. I'd like it to be often enough that if a user was shifted
he asked how often are your sessions updated? not the cluster :) The cluster will replicate changes, if any, to the other servers at the end of each request. the replication request is synchronous (default conf) so the data will be replicated by the time the user does his next request Filip ----- Original Message ----- From: "MITCHELL TEIXEIRA" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "'Dale, Matt'" <[EMAIL PROTECTED]> Sent: Tuesday, October 05, 2004 3:19 PM Subject: RE: Cluster Pure Tomcat with Hardware Load Balancer Thanks for the reply - this is the type of user experience input I'm looking for! I'm in a all or nothing situation where I need to make this work as soon as possible without too much time for meddling - if it doesn't work straightaway, I'll have to roll back to the current configuration of single server! I'm expecting perhaps 200-300 concurrent user sessions during peak times. These peaks should be brief. As for how often the sessions are updated, I don't know. I'd like it to be often enough that if a user was shifted between servers between page accesses, it would not matter! Is that reasonable? What else should I be thinking about? Regards, MitchellT -----Original Message----- From: Dale, Matt [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 3:46 PM To: Tomcat Users List Subject: RE: Cluster Pure Tomcat with Hardware Load Balancer I've set up both windows and unix/linux clusters. Using multicast, it only send out the ping every few minutes so I can't imagine either a CPU or a network problem with this. The session replication is entirely down to how often the sessions are updated and how big they are. For me, getting the basic cluster up and running was just as simple as uncommenting the block, both in windows and unix although I can appreciate this may not be the case depending on if multicast is disabled on the machine. Further tweaking can obviously be done after this. One piece of advice I would give is to keep the sessions small, ie not several megabytes each, because you can run into some timeout issues. How many concurrent users are you expecting? And how often is are the sessions updated? -----Original Message----- From: MITCHELL TEIXEIRA [mailto:[EMAIL PROTECTED] Sent: 05 October 2004 19:27 To: '[EMAIL PROTECTED]' Subject: RE: Cluster Pure Tomcat with Hardware Load Balancer Thanks to all who sent a reply to my inquiry. I have seen and read (and am re-reading) the Tomcat Clustering HOW-TO, but that info seems very limited. I'm looking for real-life information from people who have actually set this up in a Windows 2000 environment, specifically (forgot to mention that before). I'm curious about how "chatty" my two clustered servers will become. I'd like to know what works the best for session replication: Multicast or TCP unicast? How about the implications of setting up Multicast on Windows 2000? There's more to all this than just uncommenting some blocks of the server.xml! >From what I'm reading so far, it seems that Multicast is less 'chatty' on my network, but will require more CPU. I don't think that's going to be a problem, but I'm looking for some discussion about all this, whether its links to discussions, or real life experience (preferred). As for the load balancing deal: two non-clustered Tomcat servers works OK until throwing SSL (for secured shopping cart checkout) into the mix. There's lots of things that break session persistence in this scenario such as Microsoft IE 5+ browsers needing to renegotiate the SSL handshake every 2 minutes, and the megaproxy issue where ISPs such as AOL "spray" a user's browser requests through various proxy servers (all with different IPs). I run into dead-ends persuing each persistence maintenance option in load balancing, short of going the route of a SSL accelerator server or remaining on a single Tomcat server. Thanks again - MitchellT --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
