Red Hat Training

A Red Hat training course is available for JBoss Enterprise Application Platform Common Criteria Certification

7.4. Clustering

A cluster is a set of nodes. In a JBoss EAP 6 cluster, a node is a JBoss EAP 6 server instance. To build a cluster, several JBoss EAP 6 instances have to be grouped together, also known as a "partition").
Clustering allows the execution of applications on several parallel nodes. Two cluster concepts are possible with JBoss EAP 6: a failover cluster, and a load-distribution cluster. In both cases, the server state is distributed across different servers, and if any server fails, the application is still accessible via other cluster nodes.
Cluster communication establishes data consistency between different cluster nodes. JGroups and Infinispan provide the underlying communication, node replication, and caching services for JBoss EAP 6 clusters. These services are configured as MBeans. There is a set of Infinispan and JGroups MBeans for each type of clustering applications (for example, the Stateful Session EJBs, the distributed entity EJBs, etc.).
Infinispan provides distributed cache and state replication services for the JBoss EAP 6 cluster. A JBoss EAP 6 cluster can have multiple Infinispan MBeans: one for HTTP session replication, one for stateful session beans, one for cached entity beans, and so on.
The following information is replicated as part of cluster communication:
  • Replication of the state of a node includes the replication of HTTP sessions, EJB 3.0 session beans, EJB 3.0 entity beans, as well as Hibernate persistence objects (distributed state replication service using Infinispan).
  • Replication of the state of a node covering the replication of HTTP sessions, and EJB 2.x session beans.
  • Replication of HornetQ queues. Messages sent to a distributed queue or topic on one node are consumable on other nodes.
JBoss EAP 6 does not perform an automated replication of the JNDI state. When applications defining JNDI resources are replicated to different cluster nodes, they are newly deployed at the nodes. With this deployment, the JNDI resources are created similar to a regular deployment. System configuration changes that involve modifications of JNDI resources are replicated to the cluster nodes, and applied similarly to a local reconfiguration. The JNDI registry maintaining the JNDI mappings is managed consistently between the different cluster nodes. As JNDI does not maintain a state other than the JNDI registry, this is sufficient to ensure cluster-wide consistency of the JNDI service.
Report a bug