Say, anybody know a good reference book/website on Tomcat clustering and/or 
load-balancing that goes into all these possible permutations Mark is talking 
about?
I always thought a really good tutorial would be helpful on this top.  Alas, I 
haven't played with it enough yet to write one.

> -----Original Message-----
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, August 24, 2011 10:15 AM
> To: Tomcat Users List
> Subject: Re: jvmRoute generation
> 
> On 24/08/2011 15:07, Christopher Schultz wrote:
> > Jeffrey,
> >
> > On 8/24/2011 9:59 AM, Jeffrey Janner wrote:
> >> As Chris pointed out, it is mostly used by folks running with
> >> "sticky-sessions"
> >
> > Actually, use of the jvmRoute with non-sticky sessions seems like
> > an unnecessary step to me, since non-sticky sessions implies that
> > you either have no sessions (and it doesn't matter at all) or you
> > have replicated sessions where it doesn't matter which cluster
> > member you reach.
> >
> >> but from what I've been able to tell, most folks set up their
> >> clusters that way. It lessens the headaches.
> >
> > Practically speaking, clustering Tomcat instances means session
> > replication, which (if you ask me) does not warrant session
> > stickiness (though session replication does take some time... I
> > don't know enough about TC's clustering to know whether race
> > conditions are possible or probable).
> 
> If you use the Backup Manager you must use sticky sessions.
> 
> If you use the delta manager with asynchronous replication or if a
> client may make concurrent requests then you must use sticky sessions.
> 
> If you use the delta manager with synchronous replication and you are
> sure you will not have concurrent requests from the same client then
> you don't have to use sticky sessions.
> 
> > For my money, I'd go for sticky sessions and no replication at all.
> > If you really need cluster-wide session access, look to other
> > solutions (memcached, db-backed sessions, etc.).
> 
> If stateless isn't an option, I'd go for a correctly configured backup
> manager.
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

__________________________________________________________________________

Confidentiality Notice:  This Transmission (including any attachments) may 
contain information that is privileged, confidential, and exempt from 
disclosure under applicable law.  If the reader of this message is not the 
intended recipient you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly prohibited.  

If you have received this transmission in error, please immediately reply to 
the sender or telephone (512) 343-9100 and delete this transmission from your 
system.

Reply via email to