[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: Clustering without Apache in the front
From:       Christopher Schultz <chris () christopherschultz ! net>
Date:       2014-01-29 15:24:20
Message-ID: 52E91D24.1020307 () christopherschultz ! net
[Download RAW message or body]

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

Neven,

On 1/28/14, 8:59 PM, Neven Cvetkovic wrote:
> Ultimately, session stickiness works great to handle load
> balancing (workload management), but it is not enough for session
> failover.

Correct: session stickiness just avoids the problem of session
fail-over. If you want "proper" session fail-over, you'll need
clustering (in some form... Tomcat's clustering isn't the only game in
town of course).

> In the unlikely event that the serving tomcat instance dies, the
> user will be sent over to the other tomcat instance (that doesn't
> know anything about you, i.e. doesn't have your session data), and
> will probably need to login again.

Correct.

> Now, as Chris pointed out - it would be great to design your app 
> that it saves the intermediate work to a database or some secondary
> store that can be retrieved upon login again. Think "shopping
> cart", you are shopping around, the instance goes down, you need to
> login again, and a nice application would persist shopping cart for
> you, not so nice application would not, so when logged in again -
> the shopping cart would be available or not :)

Exactly. Our strategy - for those interested - is to include enough
information in each request / form to allow users whose work is
interrupted by a login to resume their workflow (in progress) after an
interrupted session. This has the added benefit of allowing users to
go get a cup of coffee, have their session expire, and pick-up where
they left-off after a quick re-login.

> Now, if your end users can live with that scenario - that's great -
>  no need for session replication, clustering your instances,
> network chatter, etc... It definitely simplifies the configuration
> and setup.

If a re-login meant starting-over at a user's "home page" and having
to re-start various workflows, it would be much more important for
sessions not to fail, and clustering would be more attractive.
Clustering is (from my outside perspective) fraught with performance
and stability issues -- not because the code is bad, but because the
entire strategy is resource-consuming and fragile somewhat by design.

> However, if your end users (i.e. your Service-Level-Agreement /
> SLA) do require a proper session failover, you will need some sort
> of session replication to successfully implement that feature.
> That's not trivial and depends on the appserver (e.g. Tomcat,
> JBoss, WebSphere, Weblogic). Session replication is not part of the
> official JEE/Servlet spec, but most modern and serious appservers
> would provide some way of replicating sessions and clustering
> appserver instances.

On a side-note, one of the things I'm most-often asked is if a new
login from a "second" (or third, etc.) client can immediately-expire
any pre-existing sessions from the same user. This is a pain in the
neck that I haven't put much thought into, yet. With multiple back-end
servers, it basically means that you need to re-authenticate the
validity of a session with a central authority on every request. *sigh*

> Now, if you could make you application stateless - you could
> possibly turn off the sticky sessions.  Makes things very easy to
> scale!

+1000

> 
> :))
> 
>> the only time I really need failover is when I 'might' want to
>> update the app's software. the app is quite stable now and not
>> many software changes right now, so again, there's not much of a
>> need for failover. :)

There's additional difficulty, here, especially if your application
changes radically: if you change the behavior of the web application
so much that two versions can't reasonably run next to each other
simultaneously, you'll require downtime.

We do this to ourselves at $work all the time by making structural
changes to our database that basically make it impossible to run
version X and X+1 simultaneously. The obvious approach is to much more
carefully make changes, spread the affects over more than a single
release, etc. but it turns out that 30 minutes of downtime once per
quarter for new releases just isn't that big of a deal for us, so we
don't bother to spend all those additional resources to make it happen.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJS6R0kAAoJEBzwKT+lPKRYKmQP/RWhnKWRYV0gksTSDdzQyf9f
t80TJMTk1F5sHlDBKjAxaG9EIVf8loJ7LILaKcwm1jHLjfn2CrQJKr7h0wRwJPH1
NbFaRUv4Y5KGa63ZEQQtlYYRmZxVPfLL2V1jA/g0PgOHvTWV5xoUtARryqFSZcQG
+kqOLeujPcNDtepqFNNRB0JGx0H7fNwEW/sobrIbramRieo834BsOkF7qkpEmCG1
pl2cTbTtk8O9oxz9FXXYHf5x6luXx1j2GY9Htk/ZErKveUU24oYPi99zkSfb+EeM
b7ufb6N2EfLs88mTOgRtbH+9BYJUcJ5s9i28oeMQ7bhq3a1asJz6gWllwfJSXAvJ
d4qu8NUNRe4C/CQ7XQlUhxfGdeDZZkm4q3iLLQomFWD1NdrZMawbZyRw5+BMZhgQ
rD0mT6vPawNUbQM4RGF0vDVK11Yuztgd0RAO8g7GGVO63qrCM1/olSo5OZPO2fbm
GICNYL0SbU3jQ8C6rud26uB1NCMEjE4i4LP1nRJ3iOa50A0wJcQayPJ/vf4ie21z
9ywlV1Y4QkHqUT5gTN95XnKoecO4vKKHot/s8LTsClXgU1jygL0+EfvIqWnOIYoo
e6K3IRA878B7rSKtyV2c/3CJi50KRq1LvYcLsoMKzaMIeFSOZfpcYWzD45G9/Yyk
BqgeQJd/tV6VMyOErKlK
=JlWo
-----END PGP SIGNATURE-----

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

[prev in list] [next in list] [prev in thread] [next in thread]