Why JBoss Fuse clusters scale better than MuleSoft ESB in < 5 minutes

MuleSoft clustering isnt funny-01

System scalability and reliability is critical for production integration solutions. Put simply, there must be enough processing capacity available to accept and process integration messages, meet service level agreements, help minimize response times, and improve system reliability. Clustering for on-premise and cloud environment often differ. This article focuses on on-premise clustering.

The most basic form of clustering is when server instances are configured to operate in what is known as a master-slave configuration. When configured this way, a single server acts as the master, processes integration messages, and one or more slave servers stands by ready to pick up work should the master server fail. Both JBoss Fuse and Mule ESB support this type of clustering. However, a significant downside for a master-slave cluster is that processing power is capped by the size of the individual servers used.

A more scalable cluster configuration involves using the combined capacity of multiple server instances to meet processing demands. Combined server processing power can quickly exceed what is possible using a single server. Both JBoss Fuse and Mule ESB Enterprise support multi-server clustering in an active-active configuration where all servers in the cluster can process integration messages.

However, Mule ESB has a documented eight server limit for an active-active cluster.1 If the processing power of eight servers is insufficient to concurrently process all integration flows needed for a complete integration solution deployment, Mule ESB users are forced to determine the subset of message processing volume possible within the cluster. Then the customer needs to create one or more additional clusters capable of handling the remaining integration processing load. Related to this Mule ESB cluster limitation, MuleSoft recommends that integration flows be designed using specific best practices to optimize processing of messages within its cluster limitations. MuleSoft documentation recommends that “You can set up a VM queue explicitly to load balance across nodes. Thus, if your entire application flow contains a sequence of child flows, Mule can assign each successive child flow to whichever node happens to be available at the time. Potentially, Mule can process a single message on multiple nodes as it passes through the entire application flow…”.2 This requires Mule EB developers to design and implement integration solutions specifically with clustering in mind rather than in a way that logically makes sense. This can impact both developer efficiency and long term maintenance costs for integration solutions forced to be spread over multiple flows instead of one due to technical constraints.

While there are practical limits that can vary by customer on the size of JBoss Fuse active-active clusters, there are no artificial limits in the software. As with all software, best practices for using JBoss Fuse and Camel have evolved over the years. Many of the best practices can be found on the world wide web. Others exist in books published books on Camel. Multiple books have been published by Red Hat employees who are active members of the open source community.3 However research has not uncovered any development practices that are specifically recommended when using JBoss Fuse in a clustered environment. However, if you want to follow the Mule ESB best practice for development of integration flows deployed to clusters, JBoss Fuse has SEDA4, VM5, and other components that would allow you to do so. But It isn’t required.

1“Mule High Availability (HA) Cluster Overview.” MuleSoft Documentation. MuleSoft, n.d. Web. 14 Oct. 2015. <https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-high-availability-ha-clusters#about-clustering>. See section labeled: About Clustering

2“Mule High Availability (HA) Cluster Overview.” MuleSoft Documentation. MuleSoft, n.d. Web. 14 Oct. 2015. <https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-high-availability-ha-clusters#about-queues>. See section labeled: About Queues

3“Apache Camel Book Listing.” Amazon.com. Amazon, n.d. Web. 14 Oct. 2015. <http://www.amazon.com/s/ref=nb_sb_ss_c_0_12?url=search-alias%3Dstripbooks&field-keywords=apache%2Bcamel&sprefix=apache%2Bcamel%2Caps%2C136>. Clause Ibsen and Scott Cranton are just 2 Red Hat employees who have published books

4“Chapter 127. SEDA.” Apache Camel Component Reference. Red Hat, n.d. Web. 14 Oct. 2015. <https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.2/html/Apache_Camel_Component_Reference/IDU-SEDA.html>.

5“Chapter 157. VM.” Apache Camel Component Reference. Red Hat, n.d. Web. 14 Oct. 2015. <https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.2/html/Apache_Camel_Component_Reference/IDU-VM.html>.


  1. Naishadh Sevalia

    I too tend to agree with Adil. It appears that the JBoss products are created by bundling various independent community projects. Hence when they are glued together, there are complicated setup and configurations to make.
    I could never make Fuse up and running in first shot. Most of the times zoo keeper creates problems.
    To be a good enterprise grade product, JBoss has to overcome such hurdles with good consolidated document.

    • Richard Naszcyniec

      Red Hat JBoss Middleware is always assembled using open source projects. That is part of the Red Hat magic. It is important to note that Red Hat does much more than just make sure that cross dependencies are met and compiles complete. There is a huge investment made in hardening the code, making sure it is secure, and much more that is best articulated in documents on the Red Hat web site. But at the end of the day, products like Fuse are 100% open source unlike MuleSoft and others who are even more proprietary like IBM and Oracle. JBoss Fuse developers have made great strides in making the product easier to use. Can it get better? Suer, and it will. What has been, and will continue to be a big reason why JBoss Fuse is used in so many companies and is building market share, is that it is reliable and scalable in production at an economic price point. Plain and simple. BTW, if you want to see some free and easy to follow getting started content on JBoss Fuse, check out what Christina Lin who is a Red Hat TMM has put together – http://wei-meilin.blogspot.com/

  2. Adil Arif

    The main reason why organizations choose Mulesoft over Fuse (especially ours), is that Mulesoft makes integration easy.

    To be productive on Mule, you need to learn how to drag and drop and use intuition. Even non-Java developers can become productive pretty quick. To be productive on Fuse, you need to read Camel in Action, OSGI in Action and ActiveMQ in Action. Then learn how all three technologies are combined together in Fuse. Therefore, Mulesoft only takes 4 days to get someone up to speed vs 12+ months with Fuse.

    What Red Hat really needs is a visionary like Ross Mason (Mulesoft’s founder). Someone who realizes that integration doesn’t start at the Java library level but when a developer first sits down in front of the computer.

    • Richard Naszcyniec

      Mule drag and drop development is overrated. I have a blog entry that points out its shortcomings as you do any sort of serious integration work. MuleSoft themselves have admitted that the visual datamapper was a performance failure and now use the text based dataweave technology. But that is the topic of a future post!

    • Richard Naszcyniec

      WRT to 12+ months to get up to speed with Fuse… IDC reported that organizations are achieving significant business value by using Red Hat JBoss Fuse, in particular by making their application integration and development efforts more efficient and productive. IDC calculates that the organizations they interviewed realized a three-year average return on investment (ROI) of 488% and earning back their investments in JBoss Fuse in 8.2 months by:
      1. Making application integration and development efforts more efficient and saving staff time
      2. Enabling integration and development of more business applications
      3. Driving higher application user productivity levels by giving users access to applications sooner and improving application performance
      4. Regaining productive time lost due to application downtime
      5. Cutting subscription and hardware costs of previous application integration solutions

      IDC also determined that this results in business value benefits of:
      * 51.5% more applications integrated per year
      * 40.8% fewer FTEs per application integration
      * 62.8% less application downtime related to integration
      * 18.1% improved middleware integration solution performance
      * 34.2% less costly then previous middleware integration solution

      Take some time to look over the free report – ttp://www.redhat.com/en/resources/value-red-hat-integration-products.

Leave a Reply

Your email address will not be published. Required fields are marked *