tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Papillon" <>
Subject Re: jk load balancing based upon ip address rather than session id
Date Thu, 12 Jun 2008 21:47:01 GMT
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... : JSESSIONID = D75AA77AC6FBF43F2C2DDC195DDA6D44.tomcatC : JSESSIONID = 5D211C177DFB064DEF731832CF07D693.tomcatA : 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, and 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,

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message