On 7/23/2013 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.
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").
That makes me glad that I'm the one and only for our setup, both
developer and server administrator. At least I get to choose how I want
to handle issues, whether in code or in some kind of external configuration.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
