Published on 01 Nov 2017
This article continues our introductory blog series on setting up a simple cluster with Payara Server, carrying straight on from our last blog where we set up load balancer on our cluster.
By clustering our Payara Servers together and balancing traffic between them with Apache Web Server we keep the benefits of having our application accessible from a single URL and gain the resilience and expansion prospects from having our application deployed across multiple instances.
However, an application spread over multiple instances can cause issues with your application's sessions. Previously, when hosted on a single instance, a session was something which was dependable and unlikely to change during the course of a user's browsing session. Now, however, we have sessions being created on every page load as our load balancer diligently spreads traffic across our instances. What we want is a way to have traffic as a whole balanced as users access our application, but have individual users remain on the same host for the duration of their session, so that their shopping baskets don't empty themselves every time they refresh the page. The session is stored within a cookie, which is essentially a way of getting around HTTP's stateless nature. We will need to append this cookie with the JVM route - a way of distinguishing which instance the session is attached to.
Thankfully, there is an Apache Web Server module which does just that. In this blog, we will be looking at how you configure sticky sessions using the JSESSIONID cookie and JVM routes and demonstrate them in action with the clusterjsp application.
Requirements
If you have been following this series, we are building on the previous blog where we configured load balancing for our cluster.
- One Ubuntu 16.04 host with:
- JDK8
- Apache Web Server
- Payara Server
- 1x Domain Administration Server (DAS)
- 1x Standalone instance ("local-instance")
- One Ubuntu 16.04 host with:
- JDK8
- OpenSSH
- Payara Server
- 1x Standalone instance ("second-Ubuntu-host-instance") (controlled by the DAS)
Deploying the test application
We will continue to use the clusterjsp application to demonstrate our sticky sessions. The clusterjsp application is a simple JSP page which displays some helpful data about how we have been served the web page, as well as giving us a JSESSIONID which will prove useful to demonstrate our sticky sessions. While you can view the cookie printed on the clusterjsp page, the route which we will be adding will only display within the developer console of your browser.
As before, deploy the application from the "Applications" page to both instances, leaving the default values intact for now.
On Chrome you can view your cookies on the Developer Console (F12) under Application > Storage > Cookies:
On Firefox you may need to specifically enable the "Storage" tab within the Developer Console (F12) to view cookies:
If you go to the clusterjsp page, you will see that we currently have only two cookies JSESSIONID and the JSESSIONIDVERSION (which we can safely ignore) - no other values are associated with our session, and when we refresh the page we are given a new session, often on a new machine.
Configuring Sticky Sessions
We will need to edit two places to get our sticky sessions configured. Firstly, in Apache Web Server, we will need to modify our existing load balancer to take into account our wish to remain on the same server by specifying a route identifier which maps to our Payara Server instances. Secondly, we will need to modify our Payara Server instances to have this route identifier so that traffic from Apache Web Server gets to the right host. The end result will be a JSESSIONID cookie and its initial route, separated by a period (e.g. "cac78b5a876dc8ed02e65bd3fc79.local-instance").
Modifying the site config
To configure Apache Web Server with sticky sessions, we will need to modify both our balancermembers, and our proxypass. To specify the route (which Payara Server refers to as the jvmRoute) we will need a unique value to refer to each of our instances. Luckily, since the instance name has to be unique, we can use that. Get the name of each of your Payara Server instances (in my case, "local-instance" and "second-Ubuntu-host-instance") and add route=<Instance Name> to the end of both your balancermember lines. You will also need to add "stickysession=JSESSIONID" to the ProxyPass line to define which cookie will be used to store the route data.
<Proxy "balancer://payara/">
BalancerMember "http://<Local-Instance-IP>:<Local-Instance-Port>/" route=<Instance Name>
BalancerMember "http://<Remote-Instance-IP>:<Remote-Instance-Port>/" route=<Instance Name>
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / "balancer://payara/" stickysession=JSESSIONID
ProxyPassReverse / "balancer://payara/"
Your site configuration should now look something like this:
Save your config and restart Apache Web Server with "sudo service apache2 restart" to apply your changes.
Modifying the instances
To configure Payara Server for our sticky sessions, we will only have to add the missing jvmRoute which the Payara Server instances don't currently provide.
Thankfully, within Payara Server the instance name we used in the site config is an environment variable ("com.sun.aas.instancename") which we can set in the cluster config and which will be dynamically specific for each instance (rather than having to further specify "-DjvmRoute=local-instance" and so on, for every instance).
To go to the JVM Settings page, select "cluster-config" from the page tree and then select "JVM Settings" from the list. To add the new jvmRoute variable, go to the "JVM Options" tab and click "Add JVM Option". In the box that appears, enter "-DjvmRoute=${com.sun.aas.instanceName}". This will add a new JVM variable ("-D") that sets the jvmRoute to be whatever the instance name is for any instance which references this config:
Checking our changes
With the jvmRoute added to the JVM options, we should now have sticky sessions ready to go.
Going back to our clusterjsp application, when we refresh the page Apache Web Server will now continue to send us on the same route. You can see the full cookie by again opening the Storage tab on the Developer console; as you can see our JSESSIONID has been appended with ".local-instance". If you delete the cookies and refresh the page (as if you were logging out, for instance), you will receive a new cookie and again be bound to one of the two hosts.
And with that, we have configured sticky sessions in Payara Server, thanks to some help from Apache Web Server. Our cluster of Payara Server instances has grown significantly from the start as we have added features and improved its capabilities. From here you have a solid base to expand your applications options - we've implemented a scalable system, that, while still able to be improved, is a great start to a reliable, high-availability production environment.
