Chapter 41. Externalize Sessions
41.1. Externalize Sessions
Red Hat JBoss Data Grid can be used as an external cache for containers, such as JBoss Enterprise Application Platform (EAP). This allows JBoss Data Grid to store HTTP Sessions, among other data, independent of the application layer, which provides the following benefits:
By making the application stateless additional nodes may be added to the EAP cluster without expensive data rebalancing operations. The EAP cluster may also be replaced without downtime by keeping the state in the JBoss Data Grid layer, as upgraded nodes may be brought online and retrieve the sessions.
Failover Across Data Centers
Should a data center become unavailable the session data persists, as it is stored safely within the JBoss Data Grid cluster. This allows a load balancer to redirect incoming requests to a second cluster to retrieve the session information.
Reduced Memory Footprint
There is reduced memory pressure, resulting in shorter garbage collection time and frequency of collections, as the HTTP Sessions have been moved out of the application layer and into the backing caches.
41.2. Externalize HTTP Session from JBoss EAP to JBoss Data Grid
The below procedure applies for both standalone and domain mode of EAP; however, in domain mode each server group requires a unique remote cache configured. While multiple server groups can utilize the same Red Hat JBoss Data Grid cluster the respective remote caches will be unique to the EAP server group.
The following procedures have been tested and confirmed to function on JBoss EAP 7.0 and JBoss Data Grid 7.0; when externalizing HTTP sessions with JBoss Data Grid 7.x only use these, or later, versions of each product.
For each distributable application, an entirely new cache must be created. It can be created in an existing cache container, for example, web.
Externalize HTTP Sessions
Ensure the remote cache containers are defined in EAP’s
infinispansubsystem; in the example below the
cacheattribute in the
remote-storeelement defines the cache name on the remote JBoss Data Grid server:
<subsystem xmlns="urn:jboss:domain:infinispan:4.0"> [...] <cache-container name="web" default-cache="dist" module="org.jboss.as.clustering.web.infinispan" statistics-enabled="true"> <transport lock-timeout="60000"/> <invalidation-cache name="jdg"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <remote-store remote-servers="remote-jdg-server1 remote-jdg-server2" cache="default" socket-timeout="60000" preload="true" passivation="false" purge="false" shared="true"/> </replicated-cache> </cache-container> </subsystem>
Define the location of the remote Red Hat JBoss Data Grid server by adding the networking information to the
<socket-binding-group ...> <outbound-socket-binding name="remote-jdg-server1"> <remote-destination host="JDGHostName1" port="11222"/> </outbound-socket-binding> <outbound-socket-binding name="remote-jdg-server2"> <remote-destination host="JDGHostName2" port="11222"/> </outbound-socket-binding> </socket-binding-group>
Repeat the above steps for each cache-container and each Red Hat JBoss Data Grid server. Each server defined must have a separate
Add passivation and cache information into the application’s
jboss-web.xml. In the following example
webis the name of the cache container, and
jdgis the name of the default cache located in this container. An example file is shown below:
<?xml version="1.0" encoding="UTF-8"?> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd" version="10.0"> <replication-config> <replication-granularity>SESSION</replication-granularity> <cache-name>web.jdg</cache-name> </replication-config> </jboss-web>
The passivation timeouts above are provided assuming that a typical session is abandoned within 15 minutes and uses the default HTTP session timeout in JBoss EAP of 30 minutes. These values may need to be adjusted based on each application’s workload.
41.3. Externalize HTTP Sessions from JBoss Web Server (JWS) to JBoss Data Grid
41.3.1. Externalize HTTP Session from JBoss Web Server (JWS) to JBoss Data Grid
A session manager has been provided as part of the JBoss Data Grid distribution, allowing JWS users to externalize sessions to JBoss Data Grid by integrating with an extension of Tomcat’s
Manager. This allows the Tomcat layer to remain stateless while providing session management persistence.
This manager requires the following versions, or later, be installed:
- JBoss Web Server 3.0
- JBoss Data Grid 7.1
To install this manager, for both Tomcat 7 and Tomcat 8, complete the following steps:
- Download jboss-datagrid-7.1.0-jws-library from JBoss Data Grid’s product page for the version of Tomcat in use.
- Extract the downloaded archive.
lib/directory from the extracted archive into
Define the implementation of the Session Manager in
context.xml, as seen below:
<Manager className="org.wildfly.clustering.tomcat.hotrod.HotRodManager" server_list="www.server1.com:7600;www.server2.com:7600" <!-- Additional Configuration Elements --> />
41.3.4. Session Management Details
When using the
HotRodManager all sessions are placed into the
default cache located on the Remote JBoss Data Grid server. Cache names are not configurable.
Sessions stored in JBoss Web Server are all mutable by default. If an object changes during the course of the request then it will be replicated after the request ends. To define immutable objects, use one of the following annotations:
The Wildfly specific annotation -
- Any generic immutable annotation.
- Any known immutable type from the JDK implementation.
Objects may have custom marshalling by defining an
Externalizer. By default the Wildfly
Externalizer is recognized; however, any implementation of this
Externalizer may be used. Additionally, non-serializable objects may be stored without issue as long as they have an
41.3.5. Configure the JBoss Web Server Session Manager
HotRodManager is configured by defining properties on the
Manager element inside of
context.xml. These are pulled from two separate lists:
org.apache.catalina.Manager- As the session manager implements this class many of the
Common Attributesare configurable.
ConfigurationParameters- This session manager also uses the HotRod Configuration Properties.
The following table displays all of the configurable elements
Table 41.1. Common Attributes from Tomcat’s Manager
The name of this cluster manager. The name is used to identify a session manager on a node. The name might get modified by the
The length of session ids created by this Manager, measured in bytes, excluding subsequent conversion to a hexadecimal string and excluding any JVM route information used for load balancing. This attribute is deprecated. Set the length on a nested
Name of the Java class that extends
Name of the provider to use to create the
Name of the algorithm to use to create the
Flag whether send all actions for session across Tomcat cluster nodes. If set to false, if already done something to the same attribute, make sure don’t send multiple actions across Tomcat cluster nodes. In that case, sends only the actions that have been added at last. Default is false.
There is also a property specific to the JWS
HotRodManager, shown below:
Determines whether or not all attributes that compose a session should be serialized together (
In addition to the attributes inherited from Tomcat, the
HotRodManager may use any of the properties typically available to a
RemoteCacheManager. These are outlined in HotRod Properties.
When using HotRod properties only the property name itself is required. For instance, to configure TCP KEEPALIVE and TCP NODELAY on the manager the following xml snippet would be used:
<Manager className="org.wildfly.clustering.tomcat.hotrod.HotRodManager" tcp_no_delay="true" tcp_keep_alive="true"/>