Using JDG as External Cache Container for WildFly HTTP Session Replication

External

• Externalizing Sessions with JDG https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.6/html/Administration_and_Configuration_Guide/chap-Externalize_Sessions.html

Internal

• WildFly Infinispan HTTP Session Replication Configuration

Relevance

• EAP 6.5, JDG 6.6

02/08/17 This article is obsolete, update it with the content of "c100/doc/... 2016.09.13 - V3 - JDG Implementation Recommendations.docx"

Overview

JDG can be used as an external cache container for HTTP session data within WildFly. This allows scaling of the data layer independent of the application, and enables different WildFly clusters, that may reside in various domains, to access data from the same JDG cluster.

Setup the JDG Cluster

The JDG cluster is essentially an Infinispan cluster and details on how to set up the cluster are available here:

Infinispan Configuration

The external JDG clustert thus configured will be accessed by the WildFly instance over the HotRod protocol.

A JDG cluster is capable of managing multiple cache instances. In case the JDG cluster is deployed with the only purpose of storing HTTP session state for one (or more) web applications, it is recommended to remove any other cache container (except “security") and the corresponding cache declaration, even those provided as example in the default configuration file, and only maintain a single cache container that manages a cache instance per web application. The example below assumes a single web application, and implicitly, and a single cache. The suggested name for the cache is “http-session-cache”.

Each web application will require a dedicated cache.

The relevant cache configuration is located in the “infinispan:server:core” subsystem:

<subsystem xmlns="urn:infinispan:server:core:6.4" default-cache-container="clustered">
  <cache-container name="clustered" default-cache="http-session-cache" statistics="true">
    <transport executor="infinispan-transport" lock-timeout="60000"/>
    <distributed-cache name="http-session-cache" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER"/>
  </cache-container>
  <cache-container name="security"/>
</subsystem>

Configure the WildFly Cache

For each distributable application, an entirely new WildFly cache must be created.

The first one can be created reconfiguring the existing 'web cache container. All other cache containers/caches can be removed.

        <subsystem xmlns="urn:jboss:domain:infinispan:1.5">
            <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan">
                <transport lock-timeout="60000"/>
                <replicated-cache name="repl" mode="ASYNC" batching="true">
                    <remote-store cache="http-session-cache" socket-timeout="60000" tcp-no-delay="true" shared="true" preload="false" passivation="false" fetch-state="false" purge="false">
                        <remote-server outbound-socket-binding="initial-jdg-server"/>
                    </remote-store>
                </replicated-cache>
            </cache-container>
        </subsystem>

Remote Cache preload Setting

The preload setting should be false, because If the store is configured to preload the cache, when the cache starts all data stored in the store will be pre-loaded into memory, This is rarely what we want. Clustered HTTP caches are usually large, exceeding the capacity of heap, and there's no point in loading all the HTTP sessions from the distributed cache into the memory of a node, anyway.

For more details on preload, see Cache Store Preloading.

Startup Options

The JDG-backed infinispan cache starts lazily with the default configuration. That mean it will only connect to the JDG cluster when a distributable web application is deployed. Sometimes might be desirable to start the cache and connect to the JDG server as soon as the WildFly server boots. To achieve that, configure the cache to start "EAGER":

    ...
    <replicated-cache name="repl" mode="ASYNC" batching="true" start="EAGER">
        ... 
    </replicated-cache>
    ...

Declare the Outbound Socket

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        ...
        <outbound-socket-binding name="initial-jdg-server">
            <remote-destination host="localhost" port="11222"/>
        </outbound-socket-binding>
    </socket-binding-group>

Configura the Application to be Distributable

See:

HTTP Session Replication