tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Help in diagnosing server unresponsiveness
Date Sun, 03 Feb 2013 17:39:27 GMT
Hash: SHA256


On 2/1/13 6:27 PM, Howard W. Smith, Jr. wrote:
> For now, I want a cluster of at least 2 or 3 tomcat servers for 
> fault-tolerance and load balancing.

If your requirements allow for users to have to re-authenticate when
you have a failover-event, then I highly recommend that you use
sticky-sessions /without/ session replication: performance will be
much better that way (and it's easier to configure).

> Yes, I read that it is not good for web apps to start (Java)
> threads to do background work, and per that advise, I have avoided
> that for now. so far, I have used @Asynchronous and @Schedule, very
> minimally.

The container in that case will be managing a thread pool on your
behalf. This is the recommended way to do things, but it's not
terrible if you want to manage your own thread pool for some
particular reason. But, if the container will do it for you in a
standards-compliant way, there doesn't seem to be a reason not to take
advantage of it.

> Chris, I'm glad you mentioned, "IMO session replication is a dog", 
> because honestly, I would love to avoid some of the pre-work
> required to prepare my app for session replication. I'm definitely
> interested in the 'better ways to achieve similar goals. I would
> love to have 2 or 3 instances of my web app accessing one database
> (Derby, at the present), and all 2 or 3 instances actually knowing
> about each other. :)

Well, if you can tolerate re-auth on failover, then there's nothing to
do at all: simply enable sticky-sessions and let it happen. Failovers
should be rare, anyway, right?

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message