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.

Synchronous vs. asynchronous replication is a trade-off between performance and high-availability. Synchronous replication provides full HA, but requires a per-request performance cost. Asynchronous replication 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.

Session Stickiness and Replication

Session stickiness configuration and the replication mechanism are related. Synchronous replication can technically be used with or without session stickiness. Asynchronous replication needs session stickiness to work correctly.

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. All the following configuration elements are optional:

<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-mode>?</replication-mode>
        <backups>?</backups>
        <use-jk>?</use-jk>
        <max-unreplicated-interval>?</max-unreplicated-interval>
        <snapshot-mode>?</snapshot-mode>
        <snapshot-interval>?</snapshot-interval>
        <session-notification-policy>?</session-notification-policy>
    </replication-config>
    ...
</jboss-web>

Configuration Elements

cache-name

The name of the cache that should be used for storing distributable sessions and clustering them around the cluster.

If not explicitly set in the deployment descriptor, the cache to use is the web container default set in the infinispan subsystem:

Infinispan Subsystem Default Web Container Cache

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