tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allistair Crossley" <Allistair.Cross...@QAS.com>
Subject RE: JK Sticky Session Handling with Load Balancing
Date Tue, 18 Apr 2006 16:15:36 GMT
Lol, ok ok, it works. My stupid fault. The reason my JSP does not output
the session ID is because the JSP on tomcat2 does not feature the output
statement - I added that to tomcat1's copy only

The shame.

Thanks to all for the help. 

-----Original Message-----
From: Allistair Crossley [mailto:Allistair.Crossley@QAS.com] 
Sent: 18 April 2006 17:10
To: Tomcat Users List
Subject: RE: JK Sticky Session Handling with Load Balancing

Hi,

Thanks for the suggestions, that has led to a solution I think. 

I used the EAL valve to log inbound and outbound cookies as you
suggested. 

<Valve className="org.apache.catalina.valves.ExtendedAccessLogValve"
  directory="logs"  prefix="localhost_xaccess_log." suffix=".txt"
  pattern="cs(Cookie) sc(Set-Cookie) sc-status"  />

Started both Tomcats, and put a whole bunch of requests in, including
new browsers to generate new sessions. The result was that I spotted I
made a mistake with my naming of jvmRoute which I did not realise had to
reflect the name of the worker. I had called them jvm1 and jvm2 when
they needed to be tomcat1 and tomcat2. 

This seems to have solved the actual issue, with sessions now being
maintained on the relevant server ... 

tomcat1

"Language=en; Country=US"
"JSESSIONID=45B40272D7FADB4F574B9B70B9699E51.tomcat1; Path=/" 200
"Language=en; Country=US;
JSESSIONID=45B40272D7FADB4F574B9B70B9699E51.tomcat1" - 200

tomcat2

"Language=en; Country=US"
"JSESSIONID=1299F640245D5064BFE8118092405723.tomcat2; Path=/" 200
"Language=en; Country=US;
JSESSIONID=1299F640245D5064BFE8118092405723.tomcat2" - 200

_However_ ;) The one thing I don't get is that the session id is still
blank on the JSP when served by Tomcat 2, whereas on Tomcat 1 I get
something like

ABDEFAA6D956F1DAACBB8B0A7D0238D4.tomcat1

>From JK logging I can see that the cookie does get set for Tomcat 2

[Tue Apr 18 17:07:15 2006] [1184:2312] [debug] jk_ajp_common.c (628):
Number of headers is = 3
[Tue Apr 18 17:07:15 2006] [1184:2312] [debug] jk_ajp_common.c (684):
Header[0] [Set-Cookie] =
[JSESSIONID=4CBDB4270B8239DD4A71D32529BF0A13.tomcat2; Path=/] [Tue Apr
18 17:07:15 2006] [1184:2312] [debug] jk_ajp_common.c (684):
Header[1] [Content-Type] = [text/html;charset=UTF-8] [Tue Apr 18
17:07:15 2006] [1184:2312] [debug] jk_ajp_common.c (684):
Header[2] [Content-Language] = [en-GB]
[Tue Apr 18 17:07:15 2006] [1184:2312] [debug] jk_ajp_common.c (1037):
received from ajp13 pos=0 len=1266 max=8192

And a follow-up request matches the same session ID

[Tue Apr 18 17:08:43 2006] [1184:2312] [debug] jk_lb_worker.c (514):
total sessionid is 4CBDB4270B8239DD4A71D32529BF0A13.tomcat2
[Tue Apr 18 17:08:43 2006] [1184:2312] [debug] jk_lb_worker.c (524):
searching worker for partial sessionid
4CBDB4270B8239DD4A71D32529BF0A13.tomcat2
[Tue Apr 18 17:08:43 2006] [1184:2312] [debug] jk_lb_worker.c (532):
searching worker for session route tomcat2 [Tue Apr 18 17:08:43 2006]
[1184:2312] [debug] jk_lb_worker.c (541):
found worker tomcat2 for route tomcat2 and partial sessionid
4CBDB4270B8239DD4A71D32529BF0A13.tomcat2

So I am not sure why my JSP is unable to get a handle on the session ID
for tomcat2 sessions only.

Best regards, Allistair.

-----Original Message-----
From: Rainer Jung [mailto:tomcat-user@kippdata.de]
Sent: 18 April 2006 16:08
To: Tomcat Users List
Subject: Re: JK Sticky Session Handling with Load Balancing

domain: you don't need the domain attribute. Domai has the following
purpose: Once you start replicating sessions between tomcats and you
build up a huge group of tomcat instances and break it up into smaller
groups which replicate, then you can use domain to tell lb, between
which tomcat instances you replicate the sessions.

workers with the same domain are assumed to replicate all sessions
between each other. So when lb detects a worker as being in error state,
it tries to send the request to another worker having the same domain
name as the erroneous one.

Cookies: How do you detect, if the cookie is set? You could log the
ingoing "Cookie" header to detect cookies sent by the browser and the
outgoing "Set-Cookie" header to watch which Cookies your server tries to
sent. For Apache you can include

\"%{Cookie}i\" \"%{Set-Cookie}o\"

in your LogFormat, for tomcat standalone use

http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/cat
alina/valves/ExtendedAccessLogValve.html

Any JSP called which does not use the page directive setting the session
atribute to false will use a session. On its first access tomcat should
send the cookie except you disable the cookie usage in your tomcat
configuration.


Allistair Crossley wrote:
> Edgar, Reinhard and Rainer and Tim,
> 
> I forgot to set jvmRoute in my server.xml ;)
> 
> But seriously .. many many thanks for your time. I have set the domain

> property for each worker, and matched them to jvmRoute on the Engine 
> element.
> 
> This has resolved the issue where Tomcat 1 generates new session ids 
> per request when Tomcat 2 is also running. For example, Tomcat 1 now 
> generates session Ids like this
> 
> 3A65ADAA09137DB460CB3FD8D393BF20.jvm1
> 
> I've been able to get requests into Tomcat 1 that stick with Tomcat 1 
> perfectly alright which is an improvement.
> 
> _However_ :) requests that get to Tomcat 2 still do not have session 
> ids returned in the headers at all. I appreciate this is Tomcat that 
> is not generating the session id, but I replicated Tomcat 2 from 
> Tomcat 1, changing server.xml's ports to be unique and I don't see 
> another reason (relative to my knowledge of course) why Tomcat 2 would

> continue to be blank for Tomcat 2. We are on an intranet, so we use 
> cookies exclusively.
> 
> Best regards, Allistair
> 
> == tomcat 1 server.xml Engine ==
> 
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
> 
> 
> == tomcat 2 server.xml Engine ==
> 
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm2">
> 
> == latest workers config ==
> 
> worker.list=loadbalancer
> 
> worker.tomcat1.domain=jvm1
> worker.tomcat1.port=8009
> worker.tomcat1.host=localhost
> worker.tomcat1.type=ajp13
> worker.tomcat1.lbfactor=1
> worker.tomcat1.cachesize=10
> 
> worker.tomcat2.domain=jvm2
> 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:ealves@mobicomp.com]
> Sent: 18 April 2006 14:36
> To: Tomcat Users List
> Subject: Re: JK Sticky Session Handling with Load Balancing
> 
> Hi again,
>   When using two workers like that you must set the domain property 
> for each of them for having mod_jk send the requests to the 
> appropriate Tomcat instance.
>   Add the following two lines to your workers properties file:
>     worker.tomcat1.domain=tomcat1
>     worker.tomcat2.domain=tomcat2
>   And for each Tomcat instance, set the "jvmRoute" attribute of the 
> Engine element in the respective server.xml configuration to the value

> that you used in the respective worker "domain" property above for 
> each instance ("tomcat1" and "tomcat2" above).
> 
>   -- Edgar Alves
> 
> 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:ealves@mobicomp.com]
>>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
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org





<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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message