> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Monday, July 22, 2013 5:45 PM > To: Tomcat Users List > Subject: Re:[OT] Enable session persistence between two tomcat nodes > behind load balancer > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Jeffrey, > > On 7/22/13 10:00 AM, Jeffrey Janner wrote: > >> -----Original Message----- From: vi...@thepenguin.org > >> [mailto:vi...@thepenguin.org] Sent: Saturday, July 20, 2013 7:25 AM > >> To: Tomcat Users List Subject: Enable session persistence between > two > >> tomcat nodes behind load balancer > >> > >> Hello: > >> > >> I have been searching for an answer to how to set this up. I find a > >> lot of posts on session persistence but none seem to describe how to > >> set it up. Is there a simple explanation out there that tells me how > >> I go about setting up session persistence (with Apache, I would just > >> set up memcached on the db server and configure the memcache module > >> on each Apache instance to point to the memcached and it works). I > >> don't need opcode persistence. I just want the tomcats to either a) > >> direct all session traffic to a single node or b) make the two > >> tomcats aware of all sessions. > >> Can someone point me in the right direction? I am not a java coder, > >> but if code changes need to be made, I can work through it. > >> > >> Thanks, > >> > >> Vicki > >> > >> > > > > Vicki - I think you've got your terms a little mixed up here, but not > > much. From your description what you are really looking for is > session > > "replication". You are in luck, because the default server.xml has a > > commented out section on how to set up replication right there (at > > least up to Tomcat 6.x). You also want to review the documentation on > > replication on the Tomcat website for your release > > (http://tomcat.apache.org). I said "not much" above, because > > replication relies on persistence-ability, meaning they both need the > > same basic setup in order to work. As I recall from looking into it > > (but not setting up a production setup), you must declare your > > sessions persistable in your code for either function to work > > properly. Jeff p.s. In case you're wondering why not production, > turns > > out our initial dev team put way too much info in the session to make > > replication a feasible option for us at the time. I think we've been > > whittling it away over time, but haven't tried it since the first > > effort. > > I've written (but not actually used - it was just a proof-of-concept) a > Filter and HttpSession wrapper that can wrap session data in an object > wrapper whose only member is a transient Object reference[1]. > This will allow you to throw "huge" objects into the session that won't > be sent across the wire (only their empty wrappers will be sent). > > If your application will tolerate a session attribute "suddenly" being > null, and can recover from that by re-building the necessary data, you > could use the same trick to enable Tomcat's session persistence. > > - -chris > > [1] You can also do something similar with WeakReference objects, which > allows you to keep huge amounts of data cached in your sessions but > allow the garbage collector to discard some of that cached data if it's > getting low on memory.
Thanks for the insight Chris, but I seriously doubt our code is that resilient. Besides, I'd much rather have code that's done "right" rather than a bunch of band-aids to work around the issues. Having a similar discussion right now about an issue that could be fixed in under 10 lines of code changes, a rebuild, and an update of the affected client (a phoneapp), but I'm have to deal with it in a massive configuration change because that's "easier" for the dev team. (Codespeack for "no one really knows how to modify phoneapp").
