Configuring High Availability with WildFly

High Availability in WildFly serves the purpose to guarantee the availability of Java EE application. As the number of request for an application increase, there are two potential issues:

  • Failure of the application, if the only node where it runs crashes.
  • Delays in serving requests, if the server is unable to handle the load.

In order to prevent these issues, WildFly supports two core features to ensure high availability of Java EE applications:

  • failover: which allows a client to continue running the application, even in case of node failure, without losing data
  • load balancing: which allows to server to provide timely responses, even in the presence of high-volumes of load

Handling WildFly failover

Failover allows a client interacting with a Java EE application to have uninterrupted access to that application, even in the presence of node failures.

For example, consider a Java EE application which makes use of the following features:

  • HTTP Session aware Servlets to provide user interaction
  • Stateful EJBs to perform state-dependent business operations
  • JPA Entity to store critical data in a persistent store
  • SSO login to the application

If the application makes use of WildFly’s fail-over services, a client interacting with an instance of that application will not be interrupted even when the node on which that instance executes crashes.

High Availability in WildFly failover High Availability in WildFly failover

Behind the scenes, WildFly makes sure that all of the user data that the application make use of are available at other nodes in the cluster, so that when a failure occurs and the client is redirected to that new node for continuation of processing, the user’s data is available and processing can continue.

The following subsystems are involved in implementing highly available applications:

  • jgroups

    JGroups is a toolkit for the underlying communication between nodes. Two main communication stacks are available in EAP: UDP (default) or TCP (no multicast).

  • infinispan

    Infinispan is used for data caching and object replication. In WildFly, Infinispan ships with 4 preconfigured caches (cluster, web, SFSB and hibernate).

  • modcluster

    mod_cluster is an httpd-based load balancer. Like mod_jk and mod_proxy, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes.

  • singleton

    The singleton subsystem can be used for the deployment of applications as highly-available singletons.

  • undertow

    Undertow is the new web server project integrated in WildFly. It is a flexible and high performing Java web server providing NIO based blocking and non-blocking APIs.

In order to allow high availability of an application using these features, it is enough to start the application server using a profile which provides high availability. For example, if you need high availability of EJB or Web applications:

$ ./ -c standalone-ha.xml

On the other hand, if you need high availability of EJB, Web and JMS applications, you have to use the full-ha profile:

$ ./ -c standalone-full-ha.xml

Check out these tutorials which are about Clustering EJB , Web and JMS applications:

EJB Applications: How to make all your EJB clusterable in JBoss/WildFly

JMS Applications: JMS Clustering in WildFly and JBoss EAP

Handling WildFly load balancing

Load balancing allows you to distribute the workload across multiple nodes, in our case, WildFly cluster nodes. This technique is used for optimizing resources, minimizing the response time, and maximizing the application throughput. To achieve load balancing, we need a component which fronts our WildFly nodes, and distributes the workload across them. A common pattern of distributing the workload is to forward client requests in a round-robin manner, so that every node serves the same number of requests.

Some options to achieve load balancing include: