Language and Page Formatting Options
Chapter 7. Clustering in Web Applications
7.1. Session Replication
7.1.1. About HTTP Session Replication
7.1.2. About the Web Session Cache
standalone-ha.xmlprofile, or the managed domain profiles
full-ha. The most commonly configured elements are the cache mode and the number of cache owners for a distributed cache.
The cache mode can either be
REPL (the default) or
REPLmode replicates the entire cache to every other node in the cluster. This is the safest option, but introduces more overhead.
DISTmode is similar to the buddy mode provided in previous implementations. It reduces overhead by distributing the cache to the number of nodes specified in the
ownersparameter. This number of owners defaults to
owners parameter controls how many cluster nodes hold replicated copies of the session. The default is
7.1.3. Configure the Web Session Cache
REPL. If you wish to use
DISTmode, run the following two commands in the Management CLI. If you use a different profile, change the profile name in the commands. If you use a standalone server, remove the
/profile=haportion of the commands.
Procedure 7.1. Configure the Web Session Cache
Change the default cache mode to
Set the number of owners for a distributed cache.The following command sets
5owners. The default is
Change the default cache mode back to
Restart the ServerAfter changing the web cache mode, you must restart the server.
Your server is configured for session replication. To use session replication in your own applications, refer to the following topic: Section 7.1.4, “Enable Session Replication in Your Application”.
7.1.4. Enable Session Replication in Your Application
To take advantage of the JBoss Enterprise Application Platform's High Availability (HA) features, configure your application to be distributable. This procedure shows how to do that, and then explains some of the advanced configuration options you can use.
Procedure 7.2. Task
Required: Indicate that your application is distributable.If your application is not marked as distributable, its sessions will never be distributed. Add the
<distributable />element inside the
<web-app>tag of your application's
web.xmldiscriptor file. Here is an example.
Example 7.1. Minimum Configuration for a Distributable Application
<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>
Modify the default replication behavior if desired.If you want to change any of the values affecting session replication, you can override them inside a
<replication-config>element which is a child element of the
<jboss-web>element. For a given element, only include it if you want to override the defaults. The following example lists all of the default settings, and is followed by a table which explains the most commonly changed options.
Example 7.2. Default
<jboss-web> <replication-config> <cache-name>custom-session-cache</cache-name> <replication-trigger>SET</replication-trigger> <replication-granularity>ATTRIBUTE</replication-granularity> <replication-field-batch-mode>true</replication-field-batch-mode> <use-jk>false</use-jk> <max-unreplicated-interval>30</max-unreplicated-interval> <snapshot-mode>INSTANT</snapshot-mode> <snapshot-interval>1000</snapshot-interval> <session-notification-policy>com.example.CustomSessionNotificationPolicy</session-notification-policy> </replication-config> </jboss-web>
Table 7.1. Common Options for session Replication
| || |
Controls which conditions should trigger session data replication across the cluster. This option is necessary because after a mutable object stored as a session attribute is accessed from the session, the container has no clear way to know if the object has been modified and needs to be replicated, unless method
Valid Values for
Regardless of the setting, you can always trigger session replication by calling
| || |
Determines the granularity of data that is replicated. It defaults to
Table 7.2. Less Commonly Changed Options for Session Replication
| || |
Whether to assume that a load balancer such as
| || |
The maximum interval (in seconds) to wait after a session before triggering a replication of a session's timestamp, even if it is considered to be unchanged. This ensures that cluster nodes are aware of each session's timestamp and that an unreplicated session will not expire incorrectly during a failover. It also ensures that you can rely on a correct value for calls to method
By default, no value is specified. This means that the
| || |
Specifies when sessions are replicated to other nodes. The default is
| || |
The interval, in milliseconds, at which modified sessions should be replicated when using
| || |
The fully-qualified class name of the implementation of interface