Hi,
1) If you want to use a mod_jk lb worker with sticky sessions, you need
three ingrediants:
a) configured lb worker with sticky_session (default is 1=on) and a
corresponding JkMount to this lb worker
b) tomcat instances with unique jvmRoute settings in server.xml (the
jvmRoute gives each instance its name) and worker configurations for the
balanced workers where the workers names are equal to the jvmRoutes and
host/port are correct for the repective tomcat instances
c) Correct configuration of URL encoding or usage of session cookies in
the target tomcat instances.
If these three conitions are met, then it works like that:
- Any request without cookie or URL encoding will go to one of your
tomcat instances. Which one depends on subtle load balancing decisions.
- Any request without cookie/encoding received by a tomcat instance will
return a response with a JSESSIONID-cookie or URL encoding of all
embedded links (assuming c)). The cookie resp. URL encoding will end in
a dot "." appended with the jvmRoute of the tomcat instance.
- Following requests with cookie or URL will be processed by the lb as
follows: It will search for a dot '.' in the cookie (with name
JSESSIONID) resp. in the URL part ";jsessionid=". Then it will take the
string after the dot and look in it's balanced worker table, if it can
find a worker with the same name that is not in error state and then
will send the request there. In case no such worker exists, it will
handle the request like in the first case.
Allistair Crossley wrote:
Hi Edgar,
Yep I just noticed that too :)) However, correcting this configuration
(to the below) does nothing to resolve the issue, because the lb worker
type by default has sticky_session=1. I set it explicitly anyway as
below.
However, I have noticed that in fact Tomcat 2 is not returning
JSESSIONID headers as Tomcat 1 does when both Tomcats are in.
To recap then, when only Tomcat 1 is in the loop, JSESSIONIDs are
returned and remains consistent across requests. When Tomcat 2 is
brought in, Tomcat 1 starts generating a different JSESSIONID per
request, whilst Tomcat 2 returns no JSESSIONID at all.
Thanks, Allistair
=== new config ===
worker.list=loadbalancer
worker.tomcat1.port=8009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.lbfactor=1
worker.tomcat1.cachesize=10
worker.tomcat2.port=8109
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13
worker.tomcat2.lbfactor=1
worker.tomcat2.cachesize=10
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat1,tomcat2
worker.loadbalancer.sticky_session=1
-----Original Message-----
From: Edgar Alves [mailto:[EMAIL PROTECTED]
Sent: 18 April 2006 12:32
To: Tomcat Users List
Subject: Re: JK Sticky Session Handling with Load Balancing
Hi there,
You're setting the sticky_session property for each worker. That's not
how it works.
That property is valid only for the loadbalancer and it takes a
boolean value. Set it to 'True' or '1' to get the desired effect.
Read http://tomcat.apache.org/connectors-doc/config/workers.html for
more info.
-- Edgar Alves
Allistair Crossley wrote:
Hi,
I have setup 2 Tomcats on the same machine fronted by IIS, and used a
sticky_session=1 JK (1.2.15) load-balanced setup (as printed at the
foot of this email)
I setup a JSP on both Tomcats that outputs the session ID.
With only 1 Tomcat started, making requests to the JSP results in the
same session ID being output on each request.
When I start up the 2nd Tomcat and continue making requests to the
JSP, I am switched between both Tomcats rather than staying on the
same Tomcat and therefore acquire a new session ID.
However, with the 2 Tomcat's "in the loop" the session Ids become
different *per request* no matter which Tomcat is used.
I would have expected at most 2 unique session Ids (one per Tomcat)
since with 1 Tomcat running only, the 1 unique session ID is
maintained.
I would appreciate any help or guidance as to why this may be
happening.
Cookies are enabled, and jsessionid is not being used on URLs.
Cheers, Allistair.
== config ==
worker.list=loadbalancer
worker.tomcat1.port=8009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.lbfactor=1
worker.tomcat1.cachesize=10
worker.tomcat1.sticky_session=1
worker.tomcat2.port=8109
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13
worker.tomcat2.lbfactor=1
worker.tomcat2.cachesize=10
worker.tomcat1.sticky_session=2
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat1,tomcat2
<FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE>
-------------------------------------------------------
QAS Ltd.
Registered in England: No 2582055
Registered in Australia: No 082 851 474
-------------------------------------------------------
</FONT> <FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLACK>
Disclaimer: The information contained within this e-mail is
confidential and may be privileged. This email is intended solely for
the named recipient only; if you are not authorised you must not
disclose, copy, distribute, or retain this message or any part of it. If
you have received this message in error please contact the sender at
once so that we may take the appropriate action and avoid troubling you
further. Any views expressed in this message are those of the
individual sender. QAS Limited has the right lawfully to record,
monitor and inspect messages between its employees and any third party.
Your messages shall be subject to such lawful supervision as QAS Limited
deems to be necessary in order to protect its information, its interests
and its reputation.
Whilst all efforts are made to safeguard Inbound and Outbound emails,
QAS Limited cannot guarantee that attachments are virus free or
compatible with your systems and does not accept any liability in
respect of viruses or computer problems experienced.
</FONT>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
