The load balancer supports complex topologies and failover configurations.
Using the member attribute distance you can group members.
The load balancer will always send a request to a member of lowest distance.
Only when all of those are broken, it will balance to the members of the
next higher configured distance. This allows to define priorities between
Tomcat instances in different data center locations.
When working with shared sessions, either by using session replication
or a persisting session manager (e.g. via a database), one often splits
up the Tomcat farm into replication groups. In case of failure of a member,
the load balancer needs to know, which other members share the session.
This is configured using the domain attribute. All workers
with the same domain are assumed to share the sessions.
For maintenance purposes you can tell the load balancer to not
allow any new sessions on some members, or even not use them at all.
This is controlled by the member attribute activation.
The value Active allows normal use of a member, disabled
will not create new sessions on it, but still allow sticky requests,
and stopped will no longer send any requests to the member.
Switching the activation from "active" to "disabled" some time before
maintenance will drain the sessions on the worker and minimize disruption.
Depending on the usage pattern of the application, draining will take from
minutes to hours. Switching the worker to stopped immediately before
maintenance will reduce logging of false errors by mod_jk.
Finally you can also configure hot spare workers by using
activation set to disabled in combination with
the attribute redirect added to the other workers:
# The advanced router LB worker
# Define the first member worker
# Define preferred failover node for worker1
# Define the second member worker
# Disable worker2 for all requests except failover
The redirect flag on worker1 tells the load balancer
to redirect the requests to worker2 in case that worker1 has a problem.
In all other cases worker2 will not receive any requests, thus acting
like a hot standby.
A final note about setting activation to disabled:
The session id coming with a request is send either
as part of the request URL (;jsessionid=...) or via a cookie.
When using bookmarks or browsers that are running since a long time,
it is possible to send a request carrying an old and invalid session id
pointing at a disabled member.
Since the load balancer does not have a list of valid sessions, it will
forward the request to the disabled member. Thus draining takes longer than
expected. To handle such cases, you can add a Servlet filter to your web
application, which checks the request attribute JK_LB_ACTIVATION.
This attribute contains one of the strings "ACT", "DIS" or "STP". If you
detect "DIS" and the session for the request is no longer active, delete the
session cookie and redirect using a self-referential URL. The redirected
request will then no longer carry session information and thus the load
balancer will not send it to the disabled worker. The request attribute
JK_LB_ACTIVATION has been added in version 1.2.32.