HTTP Session Replication
Internal
Overview
The web application will be clustered if its web.xml contains the <distributable> tag:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<distributable/>
<!-- ... -->
</web-app>
From a server's perspective, <distributable> tells it to use a clustered session manager, which replicates (or distributes) sessions across the cluster, so all EAP nodes can have access to it. This way if a node fails, requests can be directed to other node, which still has access to the session state.
The sever also must to be configured to support HTTP session clustering, see WildFly Server Configuration below.
WildFly-Specific Implementation
Synchronous and Asynchronous Replication
Sessions can replicate either synchronously or asynchronously.
In case of synchronous replication, the implementation of the session management makes sure a session chance is replicated before returning the HTTP response.
In case of asynchronous replication, the session management initiates the replication of the change in a separate thread and returns the HTTP response without waiting for a successful replication confirmation.
Session Stickiness and Replication
Session stickiness configuration and the replication mechanism are related.
If sticky sessions are disabled and the replication is asynchronous, it is possible that a subsequent request associated with the session arrives on a different node than the previous request, but before the change introduced by the previous request is replicated to the node. This is an invalid state, that must be avoided, because the change introduced by the subsequent request will be overwritten by the replication event, when it finally arrives. This is why non-sticky sessions and asynchronous replication must not be used together.
If sticky sessions are enabled and a node fails, the load balancer will detect the node failure and send the request to another node. The session should be available to that node because the session is replicated.
However, if asynchronous replication was used, it is possible that the last change has not been replicated to the target node at the time the subsequent request for that session arrives from the load balancer, and this is another invalid state we want to avoid.
Session Stickiness and Session Ownership
Before a node tries to use a session, it first tries to obtain the session ownership via locking. For more implementation details related to session ownership and locking see Session Ownership and Locking - Implementation Details. If sticky sessions are disabled, everytime a request for a given session bounces between nodes, it will require an RPC to obtain session ownership. This can be expensive since session ownership is acquired before the request is processed.This is why sticky session is in most cases a good idea.
WildFly-Specific Configuration
WildFly-specific HTTP session replication configuration can be specified in jboss-web.xml in the <replication-config> section:
<jboss-web>
...
<replication-config>
<cache-name>web.repl</cache-name>
<cache-name>${app.cache.container.name}.${app.cache.name}</cache-name>
<replication-trigger>SET</replication-trigger>
<replication-granularity>SESSION</replication-granularity>
</replication-config>
...
</jboss-web>
System Properties Usage
jboss-web.xml supports the usage of system properties, whose references will be replaced at deployment time with values defined in the application server's JVM. As an example, the name of the cache container and the cache name can be specified as system properties as follows:
...
<replication-config>
<cache-name>${app.cache.container.name}.${app.cache.name}</cache-name>
...
</replication-config>
...
For more details on system properties usage in jboss-web.xml, see: