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.
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 is a toolkit for the underlying communication between nodes. Two main communication stacks are available in EAP: UDP (default) or TCP (no multicast).
Infinispan is used for data caching and object replication. In WildFly, Infinispan ships with 4 preconfigured caches (cluster, web, SFSB and hibernate).
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.
The singleton subsystem can be used for the deployment of applications as highly-available singletons.
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:
$ ./standalone.sh -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:
$ ./standalone.sh -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:
- Installing mod_jk on Apache as front end to load balance requests across cluster nodes: Configuring mod_jk with WildFly/JBoss AS 7
- Installing mod_cluster on Apache as front end to load balance requests across cluster nodes: Clustering with JBoss mod_cluster
- Using WildFly as load balancer to distribute requests to the cluster nodes: Configuring WildFly as Load Balancer for a Cluster