Red Hat JBoss Enterprise Application Platform Administration I

One central feature of a cluster is cluster members communication. The JGroups subsystem provides a way for cluster members to communicate. The JGroups subsystem notifies cluster members when another member joins or leaves the cluster, and provides information about the cluster status. The internal cluster communication can be unicast or multicast.

The JGroups overlay network allows you to choose the transport for internal cluster communication, whether you use unicast or multicast communication. There are two transport types in TCP/IP: User Datagram Protocol (UDP), and Transmission Control Protocol (TCP). The main difference between UDP and TCP is that TCP guarantees the delivery of every network packet sent, but UDP does not. The use of UDP with multicast for internal cluster communications is the most efficient in terms of network usage.

JBoss EAP is preconfigured with two JGroups stacks:

Observe that both JGroups stacks use the private interface. This enables you to use a regular bind address by providing the jboss.bind.address parameter, and a different bind address for internal cluster communication by providing the jboss.bind.address.private parameter.

You can use one of the preconfigured stacks, or you can create a custom stack. By default, the UDP protocol is used to communicate between clustered nodes in the default ee JGroups channel. However, in corporate environments it is a common requirement to avoid UDP and multicast communication.

The following management CLI command configures the ee JGroups channel to use a tcp stack:

/subsystem=jgroups/channel=ee:write-attribute(
name=stack,value=tcp)

By default, the tcp stack also uses multicast to discover other cluster members by using the MPING JGroups protocol. JGroups provides other discovery protocols, such as PING, TCPPING, TCPGOSSSIP, JDBC_PING, FILE_PING, DNS_PING, or KUBE_PING. See the references section to learn more about each discovery protocol.

If you need to avoid multicast communication, then you can customize the tcp stack by changing the discovering protocol to either TCPPING or TCPGOSSIP.

To learn about the complete steps to avoid multicast communication, see the JBoss EAP 7 TCP Clustering article in the references section.

The Infinispan subsystem provides caching support for JBoss EAP, facilitating the high availability features of clustered servers.

In a clustered environment, data is replicated onto each node in the cluster. This data is stored in a cache, and the caching mechanism and features are implemented by a framework called Infinispan. In addition, to being able to configure how JBosss EAP caches data, Infinispan also provides the facilities to view runtime metrics for cache containers and caches.

A cache is defined within a cache container, or a repository for the caches. There are four preconfigured cache containers in the ha and full-ha profiles:

The following XML excerpt displays the default Infinispan configuration:

<subsystem xmlns="urn:jboss:domain:infinispan:12.0">
    <cache-container name="ejb" default-cache="dist" aliases="sfsb" modules="org.wildfly.clustering.ejb.infinispan">
        <transport lock-timeout="60000"/>
        <distributed-cache name="dist">
            <locking isolation="REPEATABLE_READ"/>
            <transaction mode="BATCH"/>
            <file-store/>
        </distributed-cache>
    </cache-container>
    <cache-container name="server" default-cache="default" aliases="singleton cluster" modules="org.wildfly.clustering.server">
        <transport lock-timeout="60000"/>
        <replicated-cache name="default">
            <transaction mode="BATCH"/>
        </replicated-cache>
    </cache-container>
    <cache-container name="web" default-cache="dist" modules="org.wildfly.clustering.web.infinispan">
        <transport lock-timeout="60000"/>
        <replicated-cache name="sso">
            <locking isolation="REPEATABLE_READ"/>
            <transaction mode="BATCH"/>
        </replicated-cache>
        <replicated-cache name="routing"/>
        <distributed-cache name="dist">
            <locking isolation="REPEATABLE_READ"/>
            <transaction mode="BATCH"/>
            <file-store/>
        </distributed-cache>
    </cache-container>
    <cache-container name="hibernate" modules="org.infinispan.hibernate-cache">
        <transport lock-timeout="60000"/>
        <local-cache name="local-query">
            <heap-memory size="10000"/>
            <expiration max-idle="100000"/>
        </local-cache>
        <local-cache name="pending-puts">
            <expiration max-idle="60000"/>
        </local-cache>
        <invalidation-cache name="entity">
            <heap-memory size="10000"/>
            <expiration max-idle="100000"/>
        </invalidation-cache>
        <replicated-cache name="timestamps"/>
    </cache-container>
</subsystem>

As a JBoss EAP administrator you might need to tune the Infinispan subsystem for better performance. See the Infinispan documentation, and the How to Configure and Tune the Session Replication for JBoss EAP knowledge base solution for more information about using Infinispan as a JBoss EAP administrator.

To start a cluster either in standalone or a managed domain mode, the servers can use the ha or full-ha profile to take advantage of the already configured cluster settings.

You must start the standalone or the managed domain instances with the jboss.node.name parameter. You must bind to an specific address because the 0.0.0.0 bind address is not valid for JBoss EAP instances that belong to a cluster.

For example, to start a standalone server instance you can use the following command:

[student@workstation bin]$ ./standalone.sh \
-Djboss.server.base.dir=/opt/jboss-eap-7.4/standalone/ \
-Djboss.node.name=jgroups-cluster1 \
-Djboss.bind.address=172.25.250.9 \
-c standalone-full-ha.xml

When a node joins a cluster, the log shows the following output:

2023-09-25 03:08:57,593 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-1,ee,jgroups-cluster1) ISPN000094: Received new cluster view for channel server: [jgroups-cluster1|1] (2) [jgroups-cluster1, jgroups-cluster2]
2023-09-25 03:08:57,596 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-1,ee,jgroups-cluster1) ISPN000094: Received new cluster view for channel web: [jgroups-cluster1|1] (2) [jgroups-cluster1, jgroups-cluster2]
...

-Djboss.socket.binding.port-offset=100

To set up a cluster in a managed domain, you need to ensure that the servers in the server groups can communicate with each other using JGroups. This can be done by configuring a server group to use the ha or full-ha profiles.

A cluster in a managed domain is configured at the server group level. To start a cluster in a managed domain:

After you configure the domain controller with an appropriate server group, start the host controllers. Any distributable application deployed onto the server group causes all of the servers in that group to become clustered.