Introduction to Mule 4: Execution Engine Threads and Concurrency

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 is a single, global thread pool for all flows. For details, see Execution Engine.

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

Mule 4.3 contains one unique thread pool, called the UBER pool. This thread pool is managed by Mule and shared across all apps in the same Mule instance. At startup, Mule introspects the available resources (such as memory and CPU cores) in the system and tunes automatically for the environment where Mule is running. This algorithm was established through performance testing and found optimal values for most scenarios.

The single thread pool allows Mule to be efficient, requiring significantly fewer threads (and their inherent memory footprint) to handle a given workload when compared to Mule 3.

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.

See Execution Engine for complete details about the new threading model and upgrade instructions.

Upgrading from Mule 4.2/4.1

If you are upgrading from Mule 4.2.x or 4.1.x to Mule 4.3.x, take the following actions:

If there are no custom threading settings applied (either through the scheduler-pools.conf file or directly in the Mule app), then no action is required.
If there are custom threading configurations applied, test your Mule applications with the default configuration.
Because of the UBER pool strategy and other performance updates implemented in Mule 4.3, you might not need custom threading configurations.
If tests confirm that a custom configuration is still necessary, a problem might exist with resource management in the application, one of the application dependencies, or the Mule instance. Using a custom configuration can lead to inefficient use of resources and might hide underlying issues.