Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (4.1)
  3. Mule 4 for Mule 3 Users
  4. Mule 4

  5. Execution Engine, Threads, and Concurrency

Introduction to Mule 4: Execution Engine Threads and Concurrency

Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended.

Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.

MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.

Mule 4 has an improved execution engine that simplifies the development and scaling of Mule apps. The underlying engine is based on a reactive, non-blocking architecture. This task-oriented execution model allows you to take advantage of non-blocking IO calls and avoid performance problems due to incorrect processing strategy configurations.

From a development point of view, there are a few major changes:

  • Exchange patterns no longer exist. All connectors receive responses. If you want to process a message asynchronously, use the Async component.

  • Every flow always uses a non-blocking processing strategy, and there is no need to configure processing strategies anymore.

  • There are three main thread pools (CPU Light, CPU Intensive, IO) shared across all apps in the same Mule instance.

Controlling Concurrency

Mule 4 decouples thread configuration from concurrency management. To control concurrency on a flow or any component that supports it, use the maxConcurrency attribute to set the number of simultaneous invocations that component can receive an any given time.

<flow maxConcurrency=“1”>
  <http:listener>
  <scatter-gather maxConcurrency=“3”>
    <route/>
    <route/>
  </scatter-gather>
</flow>

Thread Pools and Tuning apps

Based on the processing type of a component, Mule executes that component on a thread pool that is specifically tuned for that kind of work. These thread pools are managed by Mule and shared across all apps in the same Mule instance. When started, Mule introspects the available resources (such as memory and CPU cores) in the system to tune thread pools automatically for the environment where it is running. The default configuration was established through performance testing, which found optimal values for most scenarios.

Mule Event processors indicate to Mule whether they are CPU intensive, CPU light, or IO intensive operations. These workload types help Mule tune for different workloads, so you don’t need to manage thread pools manually to achieve optimum performance. Instead, Mule introspects the available resources (such as memory and CPU cores) in the system to tune thread pools automatically.

The different thread pools allow Mule to manage resources more efficiently, requiring significantly fewer threads (and their inherent memory footprint) to handle a given workload.

For more details on how the execution engine works and what configurations you can make to it, please see Execution Engine.