-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Howard,
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEOoM0ACgkQ9CaO5/Lv0PAlOwCffVnMaz9jFn+hg7pSVBZGGLCv yYEAoIqunDmRHiQvzLrtR+5UcmwTKIt0 =L0xm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
