-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Aristedes,
On 1/18/15 9:27 PM, Aristedes Maniatis wrote:
> I have some applications currently using sticky sessions in tomcat
> 7. Everything works well except that restarting tomcat requires
> disabling mod_jk new sessions to an instance, waiting for sessions
> to expire and then several hours later restarting the instance.
> This process is slow and not resilient to unexpected failures.
If users losing sessions is tolerable, then fail-over will certainly
work in unexpected failure situations.
> So I want to persist sessions and allow session failure in the
> cluster. It appears that I have several approaches:
>
> * JDBC * memcache [1] * DeltaManager * BackupManager
>
> I discounted JDBC quite quickly because I don't want to add any
> load to my existing database.
You can certainly set up a separate database just for session
persistence if you'd like.
> DeltaManager seems simple, but I'm weary of sending lots of data
> to all the nodes in my cluster (there are 12) which aren't even
> running the application.
DeltaManager doesn't scale well beyond a certain number of nodes
unless you are using multicast. I'm not sure what that magic number
is... it probably is different in every environment.
> So BackupManager seems better for my needs. However the
> documentation [2] suggests that BackupManager may not be as
> reliable.
BackupManager trades speed for safety: you lose some safety but gain a
lot of speed.
> Question 1: Is the documentation still correct after all these
> years of BackupManager being used? Is it still considered of lower
> reliability?
See above. It's only less reliable because of the design. No, that
hasn't changed.
> My next decision is between memcache and
> BackupManager/DeltaManager. memcache will require another service
> to be running, so slightly more maintenance and one more thing to
> fail. However memcache seems to be very commonly used and I'm not
> sure why. Are there benefits it will bring to this arrangement
> (such as visibility of live sessions in some sort of GUI) or
> something else I'm not seeing.
memcached isn't magic: it's just a key/value store and it's pretty
reliable. However: memcached is *not* meant to be a primary data
store. Instead, its meant to be a cache with a "real" primary store
behind it. When you restart your memcached service, it generally
flushes the cache (that is, it forgets everything).
That being said, we use it in production as a primary data store for
some data that's okay to lose if the service goes down. It's not for
user session data, but similar: if we lose all the data, some users
might be inconvenienced, but we don't lose any data that needs to
exist long-term.
In our usage scenario, memcached has never failed (/me knocks wood).
> Question 2: Are there advantages to running memcache as a session
> store? I'll be continuing to use sticky sessions since I think that
> will be more reliable (the system will survive the failure of the
> session store/replication, whatever I choose).
If you use memcached for your sessions, the session data will be
persisted to memcached whenever it is changed. If you are using sticky
sessions (a good idea in general IMO) along with that, then you can
probably assume that the current node is always the "source" of
session data, so you never have to go back into memcached to "freshen"
the session unless you are experiencing a fail-over event.
In that case, you fetch the session data from memcached on the new
node (the one that took-over for the failed one) and update the
session id (the base id will stay the same, I believe, but the node
identifier added to the end will change -- like 2389423412.node1 ->
2389423412.node2), and then the new node becomes the "source" node.
So, unless failover is actively occurring, you will only write to
memcached when session data actually changes.
Note that most of these live session-persistence schemes require that
you call HttpSession.setAttribute() on each attribute you want to
update in the backing-store. This isn't something that most people do
as a matter of course. So for example, this code:
HttpSession session = request.getSession(true);
WorkflowState ws = session.getAttribute("workflow_state");
ws.setState(WorkflowState.COMPLETED);
// end of code
...will have to change if you want the new workflow state to be pushed
back to the backing store. It's easy, you just have to remember to add
this to your code:
session.setAttribute("workflow_state", ws);
My question would be whether you are engineering to solve a problem
that does not yet exist. We went through this conversation years ago
at $work, and decided that users having to re-authenticate in the
event of a failure was an okay compromise given all the work it would
require to keep a high-availability cluster up and running. Our user's
needs simply aren't that critical.
So I'd advise you to have a frank conversation amongst your team to
decide if this is something you really want to do. You may decide that
the level of effort required to get all this working and keep it
working simply isn't justified.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUvSljAAoJEBzwKT+lPKRYC68P/2vhXxu4uYgQqVsplCGOeJYz
Dm2YiX23CMVZXExN/lE5fHS+skIiUHbSiWjfc6rPVRCvHij8/BPD9/chejwPNOIB
i9bEEOAvV6U5OR+Ab5rXLudEOsgcW/k/jSxZYBOQABIlKH2UHhSDHZx5/vnVA9j4
HXIgk7FHmGb9eLwHeCH/sS9nGLqFbQ6jdXkAkZafLntbSX6Mv2lHMFuiY37h3jrg
TUsekFGKQ8YPq/0fmNbV4Vw1Al7l108iL7cwtrT7LdmOq61r+AJhcfmZMRyF2nHH
8/dtQnAHx1a7bHLSqqt2psh5+Q6Ib5lrSQZDbMVz6VO7qrh0oW85460kFsTjIoII
pWp8U2TDKKwaRCoQ2WA7qcCUxEO38HY+E8jx02SEmMmo7Y39vrz0GBrdxBJz6g+C
gb/qY9GJU3WxwuwztT6PBz8O9DBS/dKdq2Kd8PP5CYkjmiGHIq/bjDDIxkbCyIrQ
KAUHMv9afSehUjMQZC4qL43xX/NjZZhlp+oajZDllw0TWhwBSqOg/6Dgl5WWOuvP
hN0E7soiP0Ojou1/0sjwWTaPAoTly4CwzhahC0cdEn1FmXDT2tQmXftJdTif79Vc
OpYwx7/F9juoXZtrPO3o62tG/azf9cmYatsI9ajdMz2GCir9fvjNfthXCOTD7FU8
7UQ6HXKue3M6PyeStom5
=Xc7x
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
