JBoss.org Community Documentation

Chapter 18. HTTP Services

18.1. Configuring load balancing using Apache and mod_jk
18.2. Download the software
18.3. Configure Apache to load mod_jk
18.4. Configure worker nodes in mod_jk
18.5. Configuring JBoss to work with mod_jk
18.6. Configuring HTTP session state replication
18.7. Enabling session replication in your application
18.8. Using FIELD level replication
18.9. Monitoring session replication
18.10. Using Clustered Single Sign On
18.11. Clustered Singleton Services
18.11.1. HASingletonDeployer service
18.11.2. Mbean deployments using HASingletonController
18.11.3. HASingleton deployments using a Barrier
18.11.4. Determining the master node

HTTP session replication is used to replicate the state associated with your web clients on other nodes of a cluster. Thus, in the event one of your node crashes, another node in the cluster will be able to recover. Two distinct functions must be performed:

State replication is directly handled by JBoss. When you run JBoss in the all configuration, session state replication is enabled by default. Just configure your web application as distributable in its web.xml (see below), deploy it, and its session state is automtically replicated across all JBoss instances in the cluster.

However, load-balancing is a different story; it is not handled by JBoss itself and requires an external load balancer. aThis function could be provided by specialized hardware switches or routers (Cisco LoadDirector for example) or by specialized software running on commodity hardware. As a very common scenario, we will demonstrate how to set up a software load balancer using Apache httpd and mod_jk.


A load-balancer tracks HTTP requests and, depending on the session to which the request is linked, it dispatches the request to the appropriate node. This is called load-balancing with sticky-sessions: once a session is created on a node, every future request will also be processed by that same node. Using a load-balancer that supports sticky-sessions but not configuring your web application for session replication allows you to scale very well by avoiding the cost of session state replication: each query will always be handled by the same node. But in case a node dies, the state of all client sessions hosted by this node (the shopping carts, for example) will be lost and the clients will most probably need to login on another node and restart with a new session. In many situations, it is acceptable not to replicate HTTP sessions because all critical state is stored in a database. In other situations, losing a client session is not acceptable and, in this case, session state replication is the price one has to pay.