You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tomcat Random <to...@gmail.com> on 2013/07/24 17:13:10 UTC
Confusion about session replication
Setup:
- Two physical servers each running Tomcat 7.0.42
- Brocade load balancer in front
The load balancer is set to source IP persistence for 5 minutes. This time
can be changed of course.
The thing I don't understand is 5 minutes or 5 hours - at then end that
time limit the user can be sent to the other server and lose data stored in
the session.
So why do sticky sessions matter when session replication turned on in
Tomcat? Is a performance issue?
TIA
Re: Confusion about session replication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Alec,
On 7/24/13 4:38 PM, Tomcat Random wrote:
> So set the LB stickiness to the same
> <session-timeout>n</session-timeout> number as in web.xml.
That's what I'd do, if...
>> "Assuming that the lb is updating the last-touch time for every
>> request mentioning the session"
>
> Could you explain this a little further. How would the LB be
> monitoring requests mentioning the session. Would that be a request
> that had *JSessionID *in it?
Correct. The lb needs to know that a particular user should be sent to
a specific application server. Usually, that's done by sniffing the
JSESSIONID cookie, or by reading the "jsessionid" path parameter from
the URL. In either case, the lb needs to either keep a lookup table of
session ids and backend servers to which they are bound (I believe
this is how most lbs work) or be clever enough to know that Tomcat can
give it a hint as to the server's identity -- this is what mod_jk does.
mod_jk does not maintain a huge registry of session->server mappings.
Instead, the session id has the backend-server's identity embedded in
it (it comes from the "jvmRoute" attribute of the <Engine> element in
server.xml) and knows which jvmRoute maps to which app server (you
have to configure this yourself).
I suppose a non-mod_jk lb could be taught to do this kind of thing.
I've never used one, so I can't give you any specific advice.
- -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/
iQIcBAEBCAAGBQJR8FDHAAoJEBzwKT+lPKRYt4MP/2DKgn+cAOZNSBpyttRf4gKe
ols2Y7yG15w04A+ymMaBc+vLNKAlafQMTrwkfCbfKsOP652ASs4JYIz/zXy0d5GT
IP0K2CWfhLnpoXcPxw9at7KagX8JBn+4qoQQyeZExda4x+2tnbPN1hOE1a2Aez5Y
a4NgQvggMN2azF43aJa3jlbO9jLRQDEWYXfgw9rtDALWMv+yS+c+a+wS2Fv2Nniz
I+w/yrTYFsR4IRF/upw2iHKG8SXlaJ/Q2rf3lAIP4yZtUyQPrbchs5bfnC8efpJC
CpKqmXeoQX2NH0zdOQsSIvRmmKEiKJJR6lnCoxq/ssQq16zbQG8Tb1c0GDdX4FzJ
LbMlO0XYGGnd5+X+CT4XtRxDoL8MCZf+qvYikSEO5LvTuuMdtO00JzDVvGb6qcsN
sFm28S4vN0z8P+bk9ioob5N76zWNoQAchxQtqTKJg/JI9KM/lKkQ1fw/NfcrW8Sc
AO3TrGPK2Bw0j7Q76hSDtvjiof9fk+6VgD40SEi09aneOo7a67wxq/2aPG8PchMO
eMFtICuDMX1qgDBM0mBU+ed0V1quWor1ax/20CXQYyY2BjfniEDlGz9aAn4JMz3b
OVwkHyPYmi6/FftgK4xAZM4AFlP7uRwxrYRqPuKRXu4R9wIxJwauYEoZ0p6n3Fax
jbGeRC/lwRjECS+djhEd
=8uP2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Confusion about session replication
Posted by Tomcat Random <to...@gmail.com>.
Thanks Chris - Sorry for the unintended anonymity. My name's Alec.
So set the LB stickiness to the same <session-timeout>n</session-timeout>
number as in web.xml.
"Assuming that the lb is updating the last-touch time for every request
mentioning the session"
Could you explain this a little further. How would the LB be monitoring
requests mentioning the session. Would that be a request that had *JSessionID
*in it?
TIA,
Alec
On Wed, Jul 24, 2013 at 2:30 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> To whom it may concern,
>
> (Might we know your real name? The above introduction feels so
> impersonal...)
>
> On 7/24/13 11:13 AM, Tomcat Random wrote:
> > Setup: - Two physical servers each running Tomcat 7.0.42 - Brocade
> > load balancer in front
> >
> > The load balancer is set to source IP persistence for 5 minutes.
> > This time can be changed of course.
> >
> > The thing I don't understand is 5 minutes or 5 hours - at then end
> > that time limit the user can be sent to the other server and lose
> > data stored in the session.
> >
> > So why do sticky sessions matter when session replication turned on
> > in Tomcat? Is a performance issue?
>
> Sticky sessions aren't really necessary when session replication is
> on. On the other hand, session information takes non-zero time to
> propagate between the members of the cluster, so using session
> stickiness may reduce the risk of out-of-date sessions when a user
> randomly switches servers in the middle of a series of high-rate requests.
>
> I would recommend setting the stickiness timeout to the same as the
> session timeout, assuming that the lb is updating the last-touch time
> for every request mentioning the session. If that's not happening,
> then it probably doesn't really matter what you set your session
> stickiness timeout to be.
>
> - -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/
>
> iQIcBAEBCAAGBQJR8B08AAoJEBzwKT+lPKRY7mwQAMN3eUGpNJ3ZgHQaGQbQJsel
> z93LU7OvNVDK1/I5P0HWAezYJ7CCrjKAVBz2IjXqTyeODrS8l6ubc8HKCFexPZlG
> PNBzr4TGx+OeKrlkVGWA7w8mo8LFPcWIwxKmVHPaVHBa30B4SXFXiGqanycn04F/
> VRGFBCC1R3+NLhmn7Cag3ZpfhsnCN4a3XAYy0ZvrW/rARTOpGp68kccJppgv+Uab
> RYZzmGCYQZeLfI2j7BFaAntc38di9+O8X68N/nC4GqIzE+XvDD/ZkYFlvYtzBxNn
> k4MaoRS05KV53qbZrMqSldjU+heIfufB1mF+f/xXlPkOX/fZPVsH6fxEyuS6WPl5
> 4qd/Cs5XXNEvMbz/S4JY8ZtnmSONZr8xffHfJf9rUzNiVqcXGcIOkbg00ZHViUuF
> c/0ADkbrwe8nStChlRfj6h6xybiKo7404g90PA8Op3C4CwO22SOus4tCZdDwXw5H
> N9Kv6DORgPZlH9XaBJzEf6M1n1EruOI1pQ/LC9Lbc3pSAod4QRKbP1zDmfr61UG8
> MF2fsXmvCCIie70rA2xlTk7PRpTwhPCbs7DRDrh/GavPeBomtl43fJSLfNczBMq8
> zTpWfgSgOzOi+VR0+jV2JXQTCQ17nj4Jikl3VR3rUv+11C9rxOjB6vsc3Ir/FHju
> NKrqyHotyHH10s82Do4Z
> =Cr56
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Confusion about session replication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
To whom it may concern,
(Might we know your real name? The above introduction feels so
impersonal...)
On 7/24/13 11:13 AM, Tomcat Random wrote:
> Setup: - Two physical servers each running Tomcat 7.0.42 - Brocade
> load balancer in front
>
> The load balancer is set to source IP persistence for 5 minutes.
> This time can be changed of course.
>
> The thing I don't understand is 5 minutes or 5 hours - at then end
> that time limit the user can be sent to the other server and lose
> data stored in the session.
>
> So why do sticky sessions matter when session replication turned on
> in Tomcat? Is a performance issue?
Sticky sessions aren't really necessary when session replication is
on. On the other hand, session information takes non-zero time to
propagate between the members of the cluster, so using session
stickiness may reduce the risk of out-of-date sessions when a user
randomly switches servers in the middle of a series of high-rate requests.
I would recommend setting the stickiness timeout to the same as the
session timeout, assuming that the lb is updating the last-touch time
for every request mentioning the session. If that's not happening,
then it probably doesn't really matter what you set your session
stickiness timeout to be.
- -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/
iQIcBAEBCAAGBQJR8B08AAoJEBzwKT+lPKRY7mwQAMN3eUGpNJ3ZgHQaGQbQJsel
z93LU7OvNVDK1/I5P0HWAezYJ7CCrjKAVBz2IjXqTyeODrS8l6ubc8HKCFexPZlG
PNBzr4TGx+OeKrlkVGWA7w8mo8LFPcWIwxKmVHPaVHBa30B4SXFXiGqanycn04F/
VRGFBCC1R3+NLhmn7Cag3ZpfhsnCN4a3XAYy0ZvrW/rARTOpGp68kccJppgv+Uab
RYZzmGCYQZeLfI2j7BFaAntc38di9+O8X68N/nC4GqIzE+XvDD/ZkYFlvYtzBxNn
k4MaoRS05KV53qbZrMqSldjU+heIfufB1mF+f/xXlPkOX/fZPVsH6fxEyuS6WPl5
4qd/Cs5XXNEvMbz/S4JY8ZtnmSONZr8xffHfJf9rUzNiVqcXGcIOkbg00ZHViUuF
c/0ADkbrwe8nStChlRfj6h6xybiKo7404g90PA8Op3C4CwO22SOus4tCZdDwXw5H
N9Kv6DORgPZlH9XaBJzEf6M1n1EruOI1pQ/LC9Lbc3pSAod4QRKbP1zDmfr61UG8
MF2fsXmvCCIie70rA2xlTk7PRpTwhPCbs7DRDrh/GavPeBomtl43fJSLfNczBMq8
zTpWfgSgOzOi+VR0+jV2JXQTCQ17nj4Jikl3VR3rUv+11C9rxOjB6vsc3Ir/FHju
NKrqyHotyHH10s82Do4Z
=Cr56
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org