Hi Chris, Thanks for the reply, > > Simon, > > Simon Papillon wrote: > | when there are > | several all servicing requests in a load balanced context, it doesn't > | work, because the session ids from different domains may be directed > | to different tomcat instances / containers, which then breaks the > | assumption that the SSO mechanism relies upon (that all sessions being > | held in a single container). > | > | The tomcat instances aren't in a distributed cluster and I'd like to > | keep it that way. > > Isn't this what "sticky sessions" are for? You get randomly assigned to > a server for your first request, and each subsequent request goes to > that same server (unless it goes down, in which case you have to > switch). This does not require distributable sessions. > > Does that not solve your SSO requirement? > > - -chris
Forgive me if I'm overlooking something, but as far as I understand it, the sticky session mechanism is driven off the JSESSIONID that is assigned by the tomcat container when a client first makes a request that instigates a session creation, if no JSESSIONID cookie was sent as part of the request the node is chosen according to the worker.loadbalancer.method (Request, Session, Traffic, Busyness i think Request is the default) . Once a JSESSIONID has been set by a container the load balancer will then attach the JVMRoute onto the end which will then be used by the jk load balancer in future requests to determine the node to use to service the request. e.g. if I have three nodes (tomcatA, tomcatB, tomcatC) I could have the following scenario... child.first-domain.com : JSESSIONID = D75AA77AC6FBF43F2C2DDC195DDA6D44.tomcatC doctor.second-domain.com : JSESSIONID = 5D211C177DFB064DEF731832CF07D693.tomcatA nurse.third-domain.co.uk : JSESSIONID = E1EC672CAAA3F2F8348C2A23991DF46B.tomcatB Where my browser has made three seperate requests for three seperate resources, all serviced by the same group of tomcat containers through vhosting, behind the load balancer, in which case my SSO mechanism won't work as future requests on child.first-domain.com, doctor.second-domain.com and nurse.third-domain.co.uk will behandled by tomcatC, tomcatA and tomcatB respectively. As the SSO mechanism is based on the assumption that all requests from the same browser are handled by the same container, this will break the SSO, Let me know if I'm misunderstanding some fundermental way in which the jk load balancer works, or if I'm not explaing myself well, Cheers Simon --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
