Session Replication in Payara Server with Hazelcast

*Note: This blog post is an update to Dynamic Clustering and Failover on Payara Server With Hazelcast, which was written for Payara Server 4.

Introduction

This article continues our introductory blog series on setting up a simple deployment group with Payara Server, carrying straight on from our last blog where we configured sticky sessions for Payara Server.

If you have been following this series, so far we have:

• Set up Apache Web Server on Ubuntu.
• Set up forwarding to the Payara Server DAS.
• Created two “standalone” Payara Server instances, sharing the same configuration and forming the same deployment group.
• Configured Apache Web Server to serve requests to each instance equally, binding each session to a specific instance so as to not interrupt session state.

This works quite well so far, and presuming your servers are the electronic equivalent of Wolverine and never die, that’s all good. If however, like the rest of us, you anticipate a server at some point needing to go down, you might wonder what will happen to any active sessions on that instance. Using the ‘sticky session’ approach from the last blog post will mean that when a server goes down, all session data is lost. This is a problem for most applications. To prevent this, you can use ‘session replication’ to ensure that there is always another instance with a copy of the session data from any other instance. This means that from a user’s perspective, it will be nearly impossible to tell when a server goes down. This provides several benefits, not least of which is the ability to perform a rolling upgrade on instances one at a time with no downtime. This blog will demonstrate how to enable session replication, to allow this functionality.

Web Container Availability

In order to allow session replication, web container availability must first be enabled. This allows web container managed properties such as sessions to be shared across instances with the same configuration.

With your instances started and referencing the same config, any change made to the shared config (in this case dg-config) will apply to both of our instances (as well as any other instances we create which reference dg-config). Previously in Payara Server 4, you had to enable Hazelcast and configure availability manually. This is all configured by default in Payara 5. In case you’ve changed any of the configuration, check that the availability service is enabled and the persistence type is ‘hazelcast’ in the Web Container Availability page:

Application Distributable Tag

The Servlet 3.1 specification defines a tag for the application web.xml (in src/main/webapp/WEB-INF). This tag is the <distributable/> tag. It is defined as follows:

Once this tag is included, your application will be marked as being appropriate to be deployed in a distributed Servlet container. In the context of a deployment group deployed application, it allows sessions to be replicated.

Serialisation

Configuration wise, the above steps should be all you need to get session replication working. However, replication requires that the user session be serialisable (to send to the other instances). If you’re storing objects in your session, make sure that each of these objects is serialisable. To do this make sure that all objects as well as each of their fields either directly or indirectly implements the Serializable interface.

Need Help Using Payara Server? Learn About Our Support Options:

{{cta(‘2701aff7-585c-4b76-b77f-32ee1b11c47a’)}}