Hi, please do not mix up the tomcat cluster and apache load balancing. Sticky session means that tomcat2 is not used at all in your configuration. Only tomcat1, which created the cookie.
When tomcat2 creates no session, the browser gets none and the lb-worker cannot work also. Maybe your apps/configurations are not consistent? Again: when tomcat does not create a session, this has nothing to do with mod_jk. Not the request starts a session, tomcat does it! regards, Reinhard Am Dienstag, 18. April 2006 13:43 schrieb Allistair Crossley: > 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] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
