Contact Free trial Login

Evaluating Mule High Availability Clusters Demo

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.


Mule ESB Enterprise supports scalable clustering to provide high availability (HA) for applications.

You can cluster two or more Mule instances together in an active-active model to manage failover and ensure reliability. Because they are built on Mule’s in-memory data grid, clustered Mule instances can run the same applications, and actively share the workload between them. If one instance, or node, fails, the others seamlessly pick up the load without interrupting service.

What is High Availability?

High Availability is a method of designing a computer system to prevent any downtime for the applications that run on it. Some systems use multiple servers so that if one server experiences downtime, the application can continue to run smoothly on the others, without interrupting service for the application’s end users.

Cluster Design and Management

The Mule Management Console is the interface that enables you to set up a cluster of Mule instances, then deploy an application to run on the cluster. In the management console, you can also monitor the status information for both clusters and individual nodes. When clustered, you can easily manage several servers as one.

A Mule ESB Cluster consists of 2 - 8 Mule ESB server instances, or nodes, grouped together and treated as a single unit. Thus, you can deploy, monitor, or stop all the nodes in a cluster as if they were a single Mule server. All the nodes in a cluster share memory, as illustrated below:


Mule uses an active-active model to cluster servers, rather than an active-passive model.

In an active-passive model, one server in a cluster acts as the primary, or active node, while the others are secondary, or passive nodes. The application in such a model runs on the primary server, and only ever runs on the secondary server if the first one fails. In this model, the processing power of the secondary node(s) is mostly wasted in passive waiting for the primary node to fail.

In an active-active model, no one server in the cluster acts as the primary server; all servers in the cluster support the application. This application in this model runs on all the servers, even splitting apart message processing between nodes to expedite processing across nodes.

Benefits of Clustering

High Availability: If one node fails, outstanding tasks transfer automatically to the surviving node(s), which continue to process messages, ensuring uninterrupted service.

Throughput: The nodes in a cluster work in parallel so that each processes a different message (or performs s different operation on the same message). Mule ESB uses VM queues to automatically balance the load between nodes, further optimizing throughput. By replicating the queues across the cluster, Mule ESB ensures that the first available node processes a message, and messages never get lost.

Resource Coordination: Mule ESB automatically coordinates access to each resource (such as a file server or a database table) to prevent utilization conflicts.

Scalability: Add or subtract Mule instances from your cluster to efficiently manage increases or decreases in load. You can also scale each instance internally to maximize its processing efficiency. In other words, a single Mule instance can take advantage of the increased processing power offered by multiple nodes within the cluster, even though that instance continues to act as a single node within the parent cluster.

Using the Demo to Explore HA

To see Mule HA clusters in action, download and install the Mule HA Demo Bundle. This free, hands-on demo helps you to quickly learn and evaluate Mule HA first-hand.

What You Will Learn

Designed to help new users evaluate the reliability of Mule High Availability Clusters, the Mule HA Demo Bundle teaches you how to use the Mule Management Console to create a cluster of Mule instances, then deploy an application to run on the cluster. Further, this demo simulates two processing scenarios that illustrate the cluster’s ability to automatically balance normal processing load, and its ability to reliably remain active in a failover situation.

What You Will Not Learn!
The Mule HA Demo Bundle demonstrate the power, agility and reliability of using a Mule cluster. Within the context of this example, the Mule cluster does not demonstrate its ability to improve processing performance. That is a demo for another day!

Included in the Demo Bundle

The Mule HA Demo Bundle includes several items which enable you to examine a functional Mule cluster.

  1. *A Mule ESB bundled distribution*which includes:

    • Mule ESB Enterprise standalone

    • Mule Management Console

  2. A demo application to deploy on the cluster.
    This cluster-demo-app consists of four flows. The application receives messages from a JMS queue, adds information to the messages, then dispatches them to another JMS queue. It uses two types of transactions to safely process messages:

    • XA between JMS and VM queues

    • local between VM endpoints
      We use a high availability cluster to run this demo because the application conducts transactions; an HA cluster guarantees that messages don’t get lost when a node becomes unavailable.

  3. A Web application, WidgetUI, to apply load to the Mule cluster.
    The Web application simulates calls to the cluster-demo-app that runs on the cluster, thereby enabling you to witness cluster reliability. When the WidgetUI Web app applies load to the cluster, you can examine statistics that illustrate how the Mule cluster balances load when processing messages.


Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub