Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: Sticky Sessions ? |
|
| Author |
|
SMc
Joined: 12 Feb 2006
Posts: 17
Location: Chelmsford, UK
|
 Posted: Wed 08 Mar '06 12:31 Post subject: Sticky Sessions ? |
 |
|
Hi,
I am running two instances of Tomcat in a loadbalancing setup.
Application works fine apart from one thing. If I logon to my administrator panel and update something, the name of the thread changes from [ajp-8009-1] to [ajp-8109-1] and the second instance doesn't know the user has logged in !
I have pasted the workers.properties file below in the hope that someone can offer a hint....
Regards,
SMc
workers.properties
----------------------
# Load Balance application between two instances of Tomcat
worker.list=loadbalancer,jkstatus
worker.tomcat1.port=8009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.lbfactor=1
worker.tomcat1.socket_timeout=1800
worker.tomcat1.recycle_timeout=1800
worker.tomcat1.cache_timeout=1800
worker.tomcat1.socket_keepalive=1
worker.tomcat2.port=8109
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13
worker.tomcat2.lbfactor=1
worker.tomcat2.socket_timeout=1800
worker.tomcat2.recycle_timeout=1800
worker.tomcat2.cache_timeout=1800
worker.tomcat2.socket_keepalive=1
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_sessions=true
worker.loadbalancer.sticky_session_force=false
worker.loadbalancer.balance_workers=tomcat1,tomcat2
worker.jkstatus.type=status |
|
| Back to top |
|
James Blond
Moderator
Joined: 19 Jan 2006
Posts: 7371
Location: Germany, Next to Hamburg
|
|
| Back to top |
|
SMc
Joined: 12 Feb 2006
Posts: 17
Location: Chelmsford, UK
|
| Posted: Wed 08 Mar '06 15:29 Post subject: |
|
|
Hi,
...yep, I seem to have set up everything as in the articles.
There must be something simple I have overlooked.....
Thanks
SMc |
|
| Back to top |
|
James Blond
Moderator
Joined: 19 Jan 2006
Posts: 7371
Location: Germany, Next to Hamburg
|
| Posted: Wed 08 Mar '06 15:51 Post subject: |
|
|
From the official Doc's
| Quote: |
The load-balancing worker does not really communicate with Tomcat workers. Instead it is responsible for the management of several "real" workers. This management includes:
Instantiating the workers in the web server.
Using the worker's load-balancing factor, perform weighed-round-robin load balancing where high lbfactor means stronger machine (that is going to handle more requests)
Keeping requests belonging to the same session executing on the same Tomcat worker.
Identifying failed Tomcat workers, suspending requests to them and instead fall-backing on other workers managed by the lb worker.
The overall result is that workers managed by the same lb worker are load-balanced (based on their lbfactor and current user session) and also fall-backed so a single Tomcat process death will not "kill" the entire site. The following table specifies properties that the lb worker can accept:
balanced_workers is a comma separated list of workers that the load balancer need to manage. These workers should not appear in the worker.list property.
sticky_session specifies whether requests with SESSION ID's should be routed back to the same Tomcat worker. If sticky_session is an int and is not 0 it is set to JK_TRUE and sessions are sticky, otherwise sticky_session is set to false. Set sticky_session to JK_FALSE when Tomcat is using a Session Manager which can persist session data across multiple instances of Tomcat. By default sticky_session is set to JK_TRUE.
The worker balance1 while use "real" workers worker1 and worker2
| Code: |
worker.balance1.balanced_workers=worker1, worker2
|
|
| Quote: |
With JK 1.2.x, new load-balancing and fault-tolerant support has been added via 2 new properties, local_worker_only and local_worker .
Let's take an example environment:
A cluster with two nodes (worker1+worker2), running a webserver + tomcat tandem on each node and a loadbalancer in front of the nodes.
The advanced router LB worker
| Code: |
worker.list=router
# Define a 'local_worker' worker using ajp13
worker.worker1.port=8009
worker.worker1.host=node1.domain.org
worker.worker1.type=ajp13
worker.worker1.lbfactor=1
worker.worker1.local_worker=1
# Define another 'local_worker' worker using ajp13
worker.worker2.port=8009
worker.worker2.host=node2.domain.org
worker.worker2.type=ajp13
worker.worker2.lbfactor=1
worker.worker2.local_worker=0
# Define the LB worker
worker.router.type=lb
worker.router.balanced_workers=worker1,worker2
worker.router.local_worker_only=1
|
The local_worker flag on worker1 and worker2 tells the lb_worker which connections are going to the local worker.
If local_worker is an int and is not 0 it is set to JK_TRUE and marked as local worker, JK_FALSE otherwise. If in minimum one worker is marked as local worker, lb_worker is in local worker mode. All local workers are moved to the beginning of the internal worker list in lb_worker during validation.
This means that if a request with a session id comes in it would be routed to the appropriate worker. If this worker is down it will be send to the first local worker which is not in error state.
If a request without a session comes in, it would be routed to the first local worker. If all local worker are in error state, then the 'local_worker_only' flag is important. If it was set to an int and this wasn't 0 it is set to JK_TRUE, JK_FALSE otherwise. With set to JK_TRUE, this request gets an error response. If set to JK_FALSE lb_worker tries to route the request to another balanced worker.
If one of the worker was in error state and has recovered nothing changes. The local worker will be check for requests without a session id (and with a session on himself) and the other worker will only be checked if a request with a session id of this worker comes in.
Why do we need souch a complex behavior ?
We need a graceful shut down of a node for maintenance. The balancer in front asks a special port on each node periodically. If we want to remove a node from the cluster, we switch off this port. The loadbalancer can't connect to it and marks the node as down. But we don't move the sessions to another node. In this environment it is an error if the balancer sends a request without a session to an apache+mod_jk+tomcat which port is switched off. And if the load balancer determines that a node is down no other node is allowed to send a request without a session to it. Only requests with old sessions on the switched off node would be routed to this node. After some time nobody uses the old sessions and the sessions will time out. Then nobody uses this node, because all session are gone and the node is unreachable without a session-id in the request. If someone uses a session which timed out, our servlet system sends a redirect response without a session id to the browser. This is necessary for me, because on a switched off node apache and tomcat can still be up and running, but they are in an old state and should only be asked for valid old sessions. After the last session timed out, I could update the node etc. without killing sessions or moving them to another node. Sometimes we have a lot of big objects in our sessions, so it would be really time consuming to move them.
The defaults are still local_worker: 0 and local_worker_only:0
|
http://tomcat.apache.org/connectors-doc-archive/jk2/jk/workershowto.html |
|
| Back to top |
|
James Blond
Moderator
Joined: 19 Jan 2006
Posts: 7371
Location: Germany, Next to Hamburg
|
| Posted: Tue 08 May '07 12:02 Post subject: |
|
|
maybe also interesting
| Code: |
<Location /app1>
ProxyPass balancer://mycloud/app1 stickysession=JSESSION
</Location>
|
|
|
| Back to top |
|
|
|
|
|
|
