Simon Papillon wrote:
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
Sorry for my first premature post. I overlooked the followup posts.
So the problem here is, that when you switch from one context to another
there isn't yet a session on the second context, so the load balancer
might send you to a new container.
At the moment I see no way of doing such a thing with mod_jk. It could
be, that you can use mod_proxy_balancer in this case, because for
mod_proxy_balancer the name of the cookie, which helps in the load
balancing discussion, is configurable. Sou you could set a SSO-Cookie in
the first context with a path of "/".
It''s something we should think about. Actually I think about adding
JkSubWorkerIndicator, which would work analogous to JkWorkerIndicator.
So you could set an environment variable in httpd which would contain
the name of the balanvcer member, you want to choose.
Environment variable in httpd can be set by mod_setenvif and
mod_rewrite, which are both able to check various request properties.
For instance mod_rewrite can check the Cookie header, so you could
extract the name of the chosen backend via a regexp from the value of
your own SSO cookie. But it's not yet implemented. Check
mod_proxy_balancer. In general it has less features than mod_jk, but in
your case it seems there is an advantage in mod_proxy_balancer.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
