HTTP Session Replication

Internal

• Servlet Session Tracking API
• web.xml
• HTTP Session

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 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:

System Properties Usage in jboss-web.xml

WildFly Server Configuration

WildFly Infinispan HTTP Session Replication Configuration