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 session is 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.
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 [JBossWeb/Tomcat_HTTP_Session_Implementation_Details#Session_Ownership_and_Locking|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.
If sticky sessions are enabled and node1 crashes, sessions will still be available on the other node (they are replicated after all) - with the possible exception of sessions that had not yet replicated when node 1 crashed, if asynchronous replication was used. Think of async vs sync as a trade-off between performance and high-availability. Sync provides full HA, but requires a per-request performance cost. Async provides almost full HA, but with low per-request performance cost. Synchronous replication can technically be used with or without session stickiness. Asynchronous replication needs session stickiness to work correctly.
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: