You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2013/07/23 00:44:58 UTC
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: vicki@thepenguin.org
>> [mailto:vicki@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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJR7bXpAAoJEBzwKT+lPKRYJPoP/jvUj8pKElRmVfXgPGOtXRBs
nhZ/6QDlOnRRpXZStLhShDXTawGUhQ/Sbpene88ytcJ1Y0Ap5D7ZMfI0HNBmZ0Oh
UvTnzcIVjJHmhHfnMzOoVvK/+cvliUVpR0Uy2M8560xShE9nCyIEzHfFUyOWUgeC
ipqvvx88+i+BYqyuWbbjrWjIY1ALjNIgmaaSy+Is3HRKvyNGnANgGvs0bDjybu/k
lVIhRPmjKmKxS/+zDRcsPtvhvywLQUV73x2KljEPppyqf1GM7sNH8HzR0uc8cEby
Lu1TYio0XYNrY7chu1zJWFRGLgS/3QoU6xmS+vT7/4JldB8gG67yynjfxmNjPGKz
+gQi5Bgcp1QW7ecNp5PDtdHseRE5c7PKaJG34MnCe4sn62TT2M7LUd5HV/xhm1IR
+0Y9weApILQoMnmDyn/jvdeWRjQRToBcTMmwgzNleLpQYrzAr2e6bZaxpcuh0djK
77bIhBv95EfWpVkD/3BVtkY3lFndMcM8hjObTQaq8QvDVKq9AWT+pF8NL8soOcoO
GD5QpTAjA9ipnjrTAfD2+QIGbgVE7znpD4nCpZgsWqQkegxMD9VXbx6cIhEj/Pfm
l/BjwuKmCRbsUlnVh1HpqWghwEWEuGz2OTpRpckWMzwjqFhQCXAI6lJABdoSstt6
yeON50P8VPkup5cmemo8
=d83r
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Enable session persistence between two tomcat nodes behind
load balancer
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@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:chris@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: vicki@thepenguin.org
> >>>> [mailto:vicki@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.
RE: [OT] Enable session persistence between two tomcat nodes behind
load balancer
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@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:chris@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: vicki@thepenguin.org
> >>>> [mailto:vicki@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.
Re: [OT] Enable session persistence between two tomcat nodes behind
load balancer
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 7/23/13 5:51 PM, Jeffrey Janner wrote:
>> -----Original Message----- From: Christopher Schultz
>> [mailto:chris@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: vicki@thepenguin.org
>>>> [mailto:vicki@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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJR7+tLAAoJEBzwKT+lPKRYe8kQAMMOKRhHck6wjeNFzC+S64b7
GVo7VlEnCBAS+IoKbsOMsU3yb09D6Y90j3C6A7Mik7bpe7Qwg197D4+3N2stR7Rj
NkDHOk43gXe53rsxIo63ZPXFkW+zI++1vA4do3GLj5hYz+MdhzKJmMcUHf5i8fEK
PD7mvsWwk7MOrQdZSgRUOYbaRsO6MKPyOOJOiCYZ/6o8Ug7n0jInZXvq0X2w9qf9
Kg6p7daggoKiBrFjcRng+cIyfKa4mYFqZSrk/Y+bbBar1ny20XSvqRO5bnuFq08W
hEfJQwDMI4h0z9GkCAHSoXk/e3sM1RUN5VQlqG7LQ8OInxZ5PPIsq1QmrL9hhaux
5UkrvhNYl5pljqVXec6pWMvqWq6t56xZBGEfwTosoKq5ZBFbqKUiNf/qeo4Z87x+
7K20JEgNrRpBUeoLUEoxb26JSq18vwHNdoUqjibnOJsWgUJIlM7z1PCC6SI5FCQd
xx8c9bnfZjeV8D5u4eEgYjr08G7mW9lc08j5IjbagEcxOg9U24RRHgSaNn12PnJv
0Vkuo1GkLXXx/iYpFH2fQEMu5Q0ebasGawnSu+Kln/eB1wlpgPU5I0wZ3HecN8G1
8fD2wpYZvlJQdRl6hFvkKMcu4zLLb+9TkmrlrtYC4Lj8TF+IoSjG1eiIzaDvGACE
aWNEgEFU5GBAQewIv0Ce
=Oyym
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Enable session persistence between two tomcat nodes behind
load balancer
Posted by David Kerber <dc...@verizon.net>.
On 7/23/2013 5:51 PM, Jeffrey Janner wrote:
>> -----Original Message-----
>> From: Christopher Schultz [mailto:chris@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: vicki@thepenguin.org
>>>> [mailto:vicki@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Re:[OT] Enable session persistence between two tomcat nodes
behind load balancer
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@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: vicki@thepenguin.org
> >> [mailto:vicki@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").