-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Howard,

On 2/5/13 8:29 PM, Howard W. Smith, Jr. wrote:
> Chris, On Sun, Feb 3, 2013 at 12:39 PM, Christopher Schultz 
> <ch...@christopherschultz.net> wrote:
> 
>> 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).
> 
> this is very interesting but somewhat of a concern as well. does 
> failover occur when one tomcat-and-web-app instance is taking a
> long time serving one request? there are a few places/pages in my
> web app that does some heavy lifting (reports that execute SQL
> SELECT, and yes, I am using indexes along with statement caching,
> etc...), and i've seen my app failover with a 404 error (i
> currently only have one instance).

It depends on how you configure things. It's usually the lb that makes
that decision, so you configure it there. I would imagine that a good
lb would be able to do things like "guess" the health of the
backend-server and take it out of rotation if it's not healthy. mod_jk
has a variety of health-checks that you can perform to decide when a
Tomcat needs to be abandoned (perhaps temporarily).

Your app fails-over to a 404? Something must be misconfigured. Or were
you saying that your webapp returns a 404 if a query runs too long or
something... that doesn't sound optimal.

>> 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?
> 
> sticky sessions sound nice and I would love to give it a try, but 
> honestly, i don't think the endusers want to have to re-auth on 
> failover. just today, I read on the atmosphere list that sticky 
> sessions are required for using atmosphere with/in clusters. i'm 
> definitely using atmosphere, but not using sticky sessions (or 
> clusters) yet.  :(

I think if you use async replication, you must use sticky sessions
anyway, because otherwise you run the risk of having a user hit a
different server before it has been updated from a previous request
(on a different server).

- -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/

iEYEAREIAAYFAlESjtAACgkQ9CaO5/Lv0PAQtwCgvzniTJG11eoJeOJcV3Gpnz6Y
+UoAnRph0Qh6c8D5f9Mk0vHis3E1iMSy
=GDk7
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to