> -----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 typo in
the hostname in server.xml was directing her to the wrong website.
