JBoss.org Community Documentation

Chapter 20. HTTP Services

20.1. Configuring load balancing using Apache and mod_jk
20.2. Download the software
20.3. Configure Apache to load mod_jk
20.4. Configure worker nodes in mod_jk
20.5. Configuring JBoss to work with mod_jk
20.6. Configuring HTTP session state replication
20.7. Enabling session replication in your application
20.8. Using FIELD level replication
20.9. Monitoring session replication
20.10. Using Clustered Single Sign On
20.11. Clustered Singleton Services
20.11.1. HASingletonDeployer service
20.11.2. Mbean deployments using HASingletonController
20.11.3. HASingleton deployments using a Barrier
20.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.

Note

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.