On Sun, Jan 18, 2015 at 9:27 PM, Aristedes Maniatis <a...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
