On Tue, Jan 27, 2015 at 3:03 AM, Aristedes Maniatis <a...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
