You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Aristedes Maniatis <ar...@ish.com.au> on 2015/01/19 03:27:49 UTC
persisting sessions best practices
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.
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. 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. So BackupManager seems better for my needs. However the documentation [2] suggests that BackupManager may not be as reliable.
Question 1: Is the documentation still correct after all these years of BackupManager being used? Is it still considered of lower reliability?
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.
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).
Thanks for any advice
Ari
[1] https://code.google.com/p/memcached-session-manager/
[2] http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html
--
-------------------------->
Aristedes Maniatis
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: persisting sessions best practices
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: persisting sessions best practices
Posted by Daniel Mikusa <dm...@pivotal.io>.
On Tue, Jan 27, 2015 at 3:03 AM, Aristedes Maniatis <ar...@ish.com.au> wrote:
> Thank you to Dan and Chris for your valuable comments.
>
> On 1/19/15 9:21 AM, Daniel Mikusa wrote:
> > Question 1: Is the documentation still correct after all these years of
> BackupManager being used? Is it still considered of lower reliability?
> >
> > It's just saying that less people use it. Because DeltaManager is the
> default and works fine in a lot of cases, the majority of users are just
> going to stick with it. Naturally then less people use BackupManager. It's
> not implying that BackupManager has problems. I've see BackupManager used a
> bunch of times and it worked great every time.
>
>
> Great. Then just as a summary, let me outline the options:
>
> Choice 1: to stick or not to stick
> If you use sticky sessions, then any session persistence layer is just
> there as a backup in case of failure of that node. So, for example,
> memcache would be used almost entirely to write entries and is never read
> from.
You've got the gist of it. Sticky sessions get you 90% of the way there.
If that's good enough for your usage, you can stop there. If you can't
afford to lose a session then you've got to go the remaining 10% and setup
clustering or shared storage for the session data.
> If you don't use sticky sessions, then the session persistence layer
> becomes a new point of failure and needs its own redundancy and load
> balancing.
>
Correct. Tomcat's Clustering support works in a peer to peer fashion, so
data is replicated between the Tomcat nodes. If you use a session store,
session data is persisted to that store. The store itself could be a
single node or multiple nodes in an HA configuration. That's up to you
though.
Dan
>
> Choices 2: which backend
>
> * JDBC
> * memcache
> * backup manager (can only be used in sticky mode)
> * delta manager
>
>
> For my needs I think the backupManager is the way to go. No extra moving
> parts, very simple to implement and not too much extra network traffic.
>
>
> On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz wrote:
> > 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.
>
>
> This is actually designed to make our life easier with sysadmin more than
> anything. We can then take an instance offline to adjust memory usage,
> attach a profiler or anything else, without worrying about doing it out of
> hours or slowly waiting for all sessions to expire.
>
> If you have commit rights to the tomcat documentation, can I suggest that
> you add your notes about HttpSession.setAttribute(). That hint is
> absolutely invaluable!
>
> Thanks
> Ari
>
>
>
>
> --
> -------------------------->
> Aristedes Maniatis
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: persisting sessions best practices
Posted by Aristedes Maniatis <ar...@ish.com.au>.
Thank you to Dan and Chris for your valuable comments.
On 1/19/15 9:21 AM, Daniel Mikusa wrote:
> Question 1: Is the documentation still correct after all these years of BackupManager being used? Is it still considered of lower reliability?
>
> It's just saying that less people use it. Because DeltaManager is the default and works fine in a lot of cases, the majority of users are just going to stick with it. Naturally then less people use BackupManager. It's not implying that BackupManager has problems. I've see BackupManager used a bunch of times and it worked great every time.
Great. Then just as a summary, let me outline the options:
Choice 1: to stick or not to stick
If you use sticky sessions, then any session persistence layer is just there as a backup in case of failure of that node. So, for example, memcache would be used almost entirely to write entries and is never read from. If you don't use sticky sessions, then the session persistence layer becomes a new point of failure and needs its own redundancy and load balancing.
Choices 2: which backend
* JDBC
* memcache
* backup manager (can only be used in sticky mode)
* delta manager
For my needs I think the backupManager is the way to go. No extra moving parts, very simple to implement and not too much extra network traffic.
On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz wrote:
> 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.
This is actually designed to make our life easier with sysadmin more than anything. We can then take an instance offline to adjust memory usage, attach a profiler or anything else, without worrying about doing it out of hours or slowly waiting for all sessions to expire.
If you have commit rights to the tomcat documentation, can I suggest that you add your notes about HttpSession.setAttribute(). That hint is absolutely invaluable!
Thanks
Ari
--
-------------------------->
Aristedes Maniatis
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] persisting sessions best practices
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dan,
On 1/19/15 11:46 AM, Daniel Mikusa wrote:
> On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>>
>> Some things [memcached] cannot do:
>>
>> 1. Replicate to other nodes. You can do sharding, but it's
>> pretty low-brow and the shards don't actually know about each
>> other. All of the smarts are in the client. The server doesn't do
>> any of this. Evidently, there are some flavors of memcached that
>> have been hacked to provide replication to other nodes, but it's
>> not part of the main distribution and didn't seem ... safe.
>>
>>
> I believe the situation with Redis is similar. There some ways to
> do this with the stable 2.x release, but those have their are
> drawbacks. There's official clustering support in 3.0, which is
> still beta, though. It's supposed to resolve these issues.
Interesting. I also considered Voldemort, but honestly I was looking
for something that was likely to be higher-performing than a Java hash
map :) (/This/ from a Java programmer!)
>> 2. Dump its database to disk. If you restart, you lose
>> everything.
>>
>>
> You can save state with Redis. It's pretty flexible about how you
> configure it too, giving you different trade-offs between
> durability and performance.
Cool.
>> 3. Allow you to browse. Basically, if you know an item's key, you
>> can fetch its value. If you don't, you are out of luck. You can't
>> just poke around looking for things. There is no equivalent of
>> "SELECT * LIMIT 5" just to see what's in there.
>>
>
> I think you'd be looking for the "KEYS" command.
Yeah, memcached does not have that. There are ways to hack-out some
keys but there is no command to list anything.
> http://redis.io/commands/keys
>
> This is off topic, but it's really why I like Redis so I'm going to
> share. With Redis, not only can a key point to a value, but it can
> also point to other data structures like sets, lists, hashes and
> sorted sets. Something I've found to be very handy.
Well, in memcached values are binary, so you can stuff anything you
want in there.
You can serialize a whole object tree if that's what you want to do. I
can imagine that memcached + JSON is a popular combination. We just
put plain-old binary values in as keys at this point, but assuming you
can serialize to bytes (like always!), you can store anything you want
in memcached.
But it's not like a formal column-store like Cassandra, etc. where the
storage mechanism understands a bit about the structures being stored.
It's basically an implementation of Map<byte[],byte[]> and we treat it
like it's Map<byte[],Integer> because we are not really even using the
values themselves; just the keys for quick lookup.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUvVnRAAoJEBzwKT+lPKRYi9wQAJJ6rYClvss+i4/sGGaCQQXZ
MJbVpI7tkcIaz/PFOcK7o5yJXl5F+trdMnfkIM2VGV21fvbRBe28u1c6EeA8yd8P
mmuXeLjZnOSPmKngR6LgtxSC8/IAba18DeuiDBkQ/Jgw207BXBZul8ELzm1H0ihF
B8GtWv5BgvASIl7r+8MX793rfBc2qDmyfV5f56EhyodZKPuBQ+nYBwZZWoNOZN38
NxC3bs9U5+MCimVPqU8CF11m+gJXaV/sK1wqrDFJP0watHHyLJ7kHpN35RU4TeSF
mYTYbQUxPKPaIZ+dPeo2yJZJadHZ4K3IX3vC9cgIz5sayTTl6esTMclzYCGMrFBI
BRj9EywYCSWdgo7ZG6p3lZPjmXSe/oEEAt00YolpnR/jyjkyzMT/k+GoS4+1n81A
QmV0U95i3i+D6E2RCR9YGa2O1yFhk5H9BuTYq+E831vrVP+XICP6vugICYdy5KUv
IPghVDlYoUuKSe7KDDNKvKnoLKC755OHg18spjlBRsTESVm1Ht1+yscaAtlbEwWB
TeZDfLsezIns6rp/9/qt6vB9g1zTZSNvepYB3cNKBabhj7lMd0K6Zdu4bvEpxLOO
dnrEXFzByG8vQ0mi/NAWcBBZJfcDMo4IHngqi3MDFUITHukxOg1TKa2238Rxi6If
3o5leMJ4BUfBBhnfKGn0
=JnfC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] persisting sessions best practices
Posted by Daniel Mikusa <dm...@pivotal.io>.
On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Daniel,
>
> On 1/19/15 9:21 AM, Daniel Mikusa wrote:
> > I've not personally used memcache, but I have used redis, so I
> > guess that's a similar approach.
>
> Are you using Redis for session persistence?
>
Yes, but I have used it for other things. It's a good project.
>
> > The technology was a nice fit, but it didn't seem like a huge win
> > versus the out-of-the-box session replication. Both worked and
> > both were fast enough for what I needed. I stuck with the
> > out-of-the-box stuff because it's distributed and replicated by
> > default and didn't require an extra server.
>
> Aah, so you evaluated it and discarded it as an option for sessions
> because it didn't offer much over what comes with Tomcat?
>
Basically. I was curious and tried it out. It worked fine, although I
can't say I tested it exhaustively. Main reasons I stuck with clustering
support in Tomcat are a.) it's all include with Tomcat, no additional JAR's
or code needed b.) I'm very familiar with it's configuration &
troubleshooting c.) no additional server needed and d.) session data is
automatically distributed across multiple nodes with Tomcat, for Redis I'd
have to set that up or live with it being a single point of failure.
>
> > Where I've mainly used redis is in restricted environments where
> > direct communication from one node to the other is not possible,
> > like in some "cloud" environments, or when it's not as easy to
> > setup like when multicast is disabled.
>
> I'm curious because I looked at a handful of packages for this kind of
> thing (we are storing authentication nonces that need to be accessible
> from all of our Tomcat servers) and we settled on memcached if only
> for its simplicity and solid reputation.
>
> Some things it cannot do:
>
> 1. Replicate to other nodes. You can do sharding, but it's pretty
> low-brow and the shards don't actually know about each other.
> All of the smarts are in the client. The server doesn't do any
> of this. Evidently, there are some flavors of memcached that
> have been hacked to provide replication to other nodes, but
> it's not part of the main distribution and didn't seem ... safe.
>
I believe the situation with Redis is similar. There some ways to do this
with the stable 2.x release, but those have their are drawbacks. There's
official clustering support in 3.0, which is still beta, though. It's
supposed to resolve these issues.
> 2. Dump its database to disk. If you restart, you lose everything.
>
You can save state with Redis. It's pretty flexible about how you
configure it too, giving you different trade-offs between durability and
performance.
>
> 3. Allow you to browse. Basically, if you know an item's key,
> you can fetch its value. If you don't, you are out of luck. You
> can't just poke around looking for things. There is no
> equivalent of "SELECT * LIMIT 5" just to see what's in there.
>
I think you'd be looking for the "KEYS" command.
http://redis.io/commands/keys
This is off topic, but it's really why I like Redis so I'm going to share.
With Redis, not only can a key point to a value, but it can also point to
other data structures like sets, lists, hashes and sorted sets. Something
I've found to be very handy.
Dan
>
> Does Redis do any of the above?
>
> Honestly, I think what Tomcat needs is a session manager for Cassandra
> or something similar: something intended to be a primary data store
> and not a cache (like memcached is).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUvStFAAoJEBzwKT+lPKRYXP8P/iQknECivamRE2+XPH9KSnzh
> BMwnq1TudZ20qFZbwnxA33Yli4DwEM6Sug7mph+R3iDVgqkR5srMfNeGUciwwFN7
> 4IUObktVQxg21VbSachilfi2Aat33FYTlmtHf+plDQAr0ig41pOKhujuF6pWWM3V
> RNJZQgmAivQXgA86RavIaVX+7x4HeB+w8iTYQm6dGbCpTWIADeqBuT358dTKRX+D
> Ricvs1M7C37LJNCyymKSgKlxAf7MF39viW9lHBsMp45o166vWcAGjj6juNuXDyBD
> xdk6UbkqbGIQ+No1W20BQZEm7mL8cCq8NYqs6YHwf9rV3v6rP4E0CTH1ubNN4q/K
> AwWtT5ijP7xA3cPxXEs7XdL6ynsMMJublk2/+V/+ctPE2XP7kfQCMBYhPSiux1Kc
> ILikydk5u0X0Dudmes4r9g6+wabnR9OC6/lB3c6BRG6kOdbj+VJo+23vbUQZkAHt
> lCVjjTirrvb6YLXuv+IXUomAlLn7bzQ39M1L1UO5wsRUd2kICnpZ7G5Cs3n5r98B
> WWSBLvChvez/hnt2HP3PlTBstW06R1Ds9FvkSMtVoO3roQSPEx6b1QCEsnw1NXCL
> SvAgN43FzXZxOyr+ZohGzUhSELXQI5v7pV6p3Bj+tMrAL/+fzMiS4KoJqDWc7/nB
> 3NlP1g/7RN1IYnLkFm+q
> =Po13
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] persisting sessions best practices
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Daniel,
On 1/19/15 9:21 AM, Daniel Mikusa wrote:
> I've not personally used memcache, but I have used redis, so I
> guess that's a similar approach.
Are you using Redis for session persistence?
> The technology was a nice fit, but it didn't seem like a huge win
> versus the out-of-the-box session replication. Both worked and
> both were fast enough for what I needed. I stuck with the
> out-of-the-box stuff because it's distributed and replicated by
> default and didn't require an extra server.
Aah, so you evaluated it and discarded it as an option for sessions
because it didn't offer much over what comes with Tomcat?
> Where I've mainly used redis is in restricted environments where
> direct communication from one node to the other is not possible,
> like in some "cloud" environments, or when it's not as easy to
> setup like when multicast is disabled.
I'm curious because I looked at a handful of packages for this kind of
thing (we are storing authentication nonces that need to be accessible
from all of our Tomcat servers) and we settled on memcached if only
for its simplicity and solid reputation.
Some things it cannot do:
1. Replicate to other nodes. You can do sharding, but it's pretty
low-brow and the shards don't actually know about each other.
All of the smarts are in the client. The server doesn't do any
of this. Evidently, there are some flavors of memcached that
have been hacked to provide replication to other nodes, but
it's not part of the main distribution and didn't seem ... safe.
2. Dump its database to disk. If you restart, you lose everything.
3. Allow you to browse. Basically, if you know an item's key,
you can fetch its value. If you don't, you are out of luck. You
can't just poke around looking for things. There is no
equivalent of "SELECT * LIMIT 5" just to see what's in there.
Does Redis do any of the above?
Honestly, I think what Tomcat needs is a session manager for Cassandra
or something similar: something intended to be a primary data store
and not a cache (like memcached is).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUvStFAAoJEBzwKT+lPKRYXP8P/iQknECivamRE2+XPH9KSnzh
BMwnq1TudZ20qFZbwnxA33Yli4DwEM6Sug7mph+R3iDVgqkR5srMfNeGUciwwFN7
4IUObktVQxg21VbSachilfi2Aat33FYTlmtHf+plDQAr0ig41pOKhujuF6pWWM3V
RNJZQgmAivQXgA86RavIaVX+7x4HeB+w8iTYQm6dGbCpTWIADeqBuT358dTKRX+D
Ricvs1M7C37LJNCyymKSgKlxAf7MF39viW9lHBsMp45o166vWcAGjj6juNuXDyBD
xdk6UbkqbGIQ+No1W20BQZEm7mL8cCq8NYqs6YHwf9rV3v6rP4E0CTH1ubNN4q/K
AwWtT5ijP7xA3cPxXEs7XdL6ynsMMJublk2/+V/+ctPE2XP7kfQCMBYhPSiux1Kc
ILikydk5u0X0Dudmes4r9g6+wabnR9OC6/lB3c6BRG6kOdbj+VJo+23vbUQZkAHt
lCVjjTirrvb6YLXuv+IXUomAlLn7bzQ39M1L1UO5wsRUd2kICnpZ7G5Cs3n5r98B
WWSBLvChvez/hnt2HP3PlTBstW06R1Ds9FvkSMtVoO3roQSPEx6b1QCEsnw1NXCL
SvAgN43FzXZxOyr+ZohGzUhSELXQI5v7pV6p3Bj+tMrAL/+fzMiS4KoJqDWc7/nB
3NlP1g/7RN1IYnLkFm+q
=Po13
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: persisting sessions best practices
Posted by Daniel Mikusa <dm...@pivotal.io>.
On Sun, Jan 18, 2015 at 9:27 PM, Aristedes Maniatis <ar...@ish.com.au> 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.
>
> 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. 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.
I would agree. You don't want DeltaManager with that many cluster nodes.
This is just my opinion but I wouldn't go over three or four nodes with
DeltaManager.
> So BackupManager seems better for my needs. However the documentation [2]
> suggests that BackupManager may not be as reliable.
>
Agree, BackupManager seems like it'll fit your needs better.
Do you mean this comment? "Downside of the BackupManager: not quite as
battle tested as the delta manager."
>
> Question 1: Is the documentation still correct after all these years of
> BackupManager being used? Is it still considered of lower reliability?
>
It's just saying that less people use it. Because DeltaManager is the
default and works fine in a lot of cases, the majority of users are just
going to stick with it. Naturally then less people use BackupManager.
It's not implying that BackupManager has problems. I've see BackupManager
used a bunch of times and it worked great every time.
>
> 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.
>
I've not personally used memcache, but I have used redis, so I guess that's
a similar approach. The technology was a nice fit, but it didn't seem like
a huge win versus the out-of-the-box session replication. Both worked and
both were fast enough for what I needed. I stuck with the out-of-the-box
stuff because it's distributed and replicated by default and didn't require
an extra server. Where I've mainly used redis is in restricted
environments where direct communication from one node to the other is not
possible, like in some "cloud" environments, or when it's not as easy to
setup like when multicast is disabled.
Dan
> 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).
>
>
>
> Thanks for any advice
>
> Ari
>
>
>
>
> [1] https://code.google.com/p/memcached-session-manager/
> [2] http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html
> --
> -------------------------->
> Aristedes Maniatis
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>