Sticky session configuration in EAP 6 (AS 7)
- Published: 11 February 2013
In this tutorial we will test clustering & sticky sessions using the Enterprise Application Platform (EAP) 6.0.1 (AS 7.1.3).
The first thing we will see is how to install the EAP 6. If you haven't signed a contract with RedHat, you can still download a trial version from https://access.redhat.com/downloads#eval.
There are several ways to install the EAP. If you have downloaded the JAR installer, you can run it with:
java -jar jboss-eap-6.0.1-installer.jar
The installation wizard will start. At first enter the installation path:
Next enter the admin user name which will be added to the management realm to access the Management console:
Then you are asked if you want to install quickstarts demos along with your platform. Proceed to the next screen where you are allowed to select the packages you want to install and exclude some non-mandatory elements such as docs and some EAP Native utils
Finally, it's time to set up the socket binding. We can leave the default binding and continue with server installation:
Finally choose if you want to start a standalone/domain server after the installation has completed:
The last screen will recap your settings and perform the EAP installation.
Hint: if you need to perform several indentical installation, you can reuse the template XML which was created using the first installation and so automatically install it with:
java -jar jboss-eap-6.0.1-installer.jar template.xml
Now set up a cluster of application servers (You can have a look at the following tutorial for more info about it). In our example we will run test a two node clusters, using mod_cluster in front of it:
Balancing calls between server nodes:
The term "sticky session" refers to the feature of many commercial load balancing solutions to route the requests for a particular session to the same physical machine that serviced the first request for that session.
In a clustered JBoss AS calls between nodes in the cluster are, by default, balanced using the jvmRoute parameters. Earlier JBoss 4-5-6 and Tomcat developers used to enter the jvmRoute manually in the server.xml web server configuration file:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1"> ... ... </Engine>
When running JBoss EAP 6/ AS 7 the jvmRoute is automatically generated for you at cluster startup so you don't need to care about setting a unique jvmRoute:
10:01:31,141 INFO [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Engine [jboss.web] will use jvmRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516
Now let's test how sticky session works with the default value (true)
<mod-cluster-config advertise-socket="modcluster" sticky-session="true" sticky-session-force="true" connector="ajp">
Notice the other parameter: "sticky-session-force": when set to "Yes" returns an error if the request can't be routed according to JVMRoute. If set to "no" routes it to another node. Default: "Yes"
As you can see, our quintessential JSP (which dumps the sessionid), is running on the same server node between each request.
Now let's test the following configuration:
<mod-cluster-config advertise-socket="modcluster" sticky-session="false" sticky-session-force="false" connector="ajp">
As you can see, with sticky-session="false", each request is balanced across the cluster and, using the default session replication to keep data in synch between nodes.
Sticky session was a quite popular solution for applications which wanted to scale better without the need to set up a cluster where data is replicated across all server nodes. This could be applicable of course if all critical data was stored in a persistence storage so a session restart could be acceptble from this point of view.
In today's clustering architecture, which by default uses session replication to keep data in synch, this parameter is not so critical anymore. Yet you might want to experiment changing the default sticky session (true) behaviour which might cause an uneven load distribution across servers.