> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, July 24, 2013 9:57 AM > 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/23/13 5:51 PM, Jeffrey Janner wrote: > >> -----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. > > Honestly, I consider this to be a valid technique for caching rather > than just a band-aid. But the underlying code has to be tolerant, of > course. > > > 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"). > > Hah... the justification is probably that the "code has already been > tested" and configuration changes don't require re-testing. Introduce > them to the concept of automated/unit testing :) > > - -chris
In this case it really is the code-speak. Of course, configuration changes are vulnerable to bugs as well and also require testing. Discovered that truism again this morning when one of our customers couldn't login because a type in the hostname was directing her to the wrong website.
