In Mule4 the runtime engine is designed for nonblocking and asynchronous execution. Mule4 runtime is a “Reactive” execution engine.

This new runtime manage/tune different workload automatically. In means Mule Even processor itself indicate what type of operation they want follow. The operation could be CPU-light, CPU-intensive or IO-intensive.

As we all know Mule 4 runtime is based on event. And based on type of event below are the processors. They decide how a Mule component work or operate. That means, how speed a mule component will process, how many threads or which type of thread pull will allocate.

• CPU-light :
  • This processor is for quick operation. The processing speed will be around 10 ms.
  • By default, this processor does perform only NON Blocking activities.
  • Logger, HTTP Requestor component. These type of tasks will not perform any Blocking activities.
  • While running any Mule4 application, we can identify these processors in console logger.
  • From console log we can find CPU_LIGHT and CPU_LIGHT_ASYNC string, which will tell us which component is running on CPU-light processing type.


• CPU-intensive :
  • This type processor is not for quick operation. It takes more than 10 ms to perform any task/activity.
  • These tasks should not perform any I/O activity.
  • Transform Message component use this processor.
  • From Studio console log we can identify CPU_INTENSIVE string, which is give information which mule component use CPU-intensive processing type.


• Blocking IO :
  • For any operation where Mule component has to wait for response or it blocks the thread, in those operations Blocking IO will use.
  • Database select operation or SFTP read operation.
  • BLOCKING or IO in console logs will indicate us that which Mule component is using Blocking IO processing type.

Based on Mule event processing type we have 3 thread pool in Mule 4 engine.

Now we can not manage or configure the thread pools in Application levels, Instead Mule 4 engine using the thread management internally.

All these 3 pool are centralized, which will manage at runtime level. If any configuration or changes required according to Application processing, we have to handle at runtime level by using JVM parameters inside the Mule runtime.

Below are the 3 centralized thread pool which are based on Mule event process :-

• CPU_LITE
• CPU_INTENSIVE
• BLOCKING_IO

Mule Application will use threads from each pool based on event. In this thread process, a single flow can utilise multiple threads from different pool based on the usage of components.

Apart from default THREE pools Mule 4 runtime use some additional pools for specific purposes :-

• NIO Selector :- Based on requirement components use NON Blocking IO. Internally Java NIO Selector is being use most of the time by the connector or component.
• Recurring Pools :- Some connector or component can create this type of custom pool for recurring tasks.

• GRIZZLY
In Mule 4 runtime this one of the most custom thread pool being used HTTP components.
This is a NIO Selector thread pool. Java “NIO” has the concept of selector thread.
This pool is also configured at runtime level and shared by application deployed to that runtime.
GRIZZLY is devided into TWO pools. One is GRIZZLY(Shared) and other is GRIZZLY(Dedicated). The Shared one will use by HTTP Listener and HTTP Requestor will use the dedicated one.

The minimum size of thread pool will determine on CPU size, and that will decide once the runtime starts.

Here is the Mule 4 thread pool configuration, which will depend how we are configured our CPU and RAM size.

For a Mule runtime sitting on a 2 core CPU with 1 Gig machine or container, the following table shows what the minimum and maximum values are for each thread pool.

Based on performance test of a Mule Application we may have to customize our Mule engine.

To take that decision we may have to know about each pool and their usability. Which will help to perform fine tune of a Mule server for better performance.

Mule 4 calculates the sizing of thread pools dynamically and automatically, and in most scenarios the defaults are optimal. Under most circumstances it not recommended from MuleSoft to change the default values. However, this exercise has discovered the default thread pools sizing are insufficient due to the high number of HTTP requests with a relatively low memory allocation and thread pool sizing.

Here are the pool and its event processors :

The thread pool sizing is changed in the following file of the Mule runtime:

• MULE_HOME/conf/scheduler-pools.conf

The thread pool is automatically configured by Mule at startup, applying formulas that consider available resources such as CPU and memory.

We can modify these global formulas by editing the MULE_HOME/conf/schedulers-pools.conf file in our local Mule instance.

In Mule we have TWO Scheduling Strategy

•   UBER :- Unified scheduling strategy. (Default)
•   DEDICATED :- Separated pools strategy. (Legacy)

• UBER Scheduling Strategy
When the strategy is set to UBER, the following configuration applies:
• org.mule.runtime.scheduler.uber.threadPool.coreSize=cores
• org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + mem - 245760) / 5120
• org.mule.runtime.scheduler.uber.workQueue.size=0
• org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000
• DEDICATED Scheduling Strategy
When the strategy is set to DEDICATED, the parameters from the default UBER strategy are ignored.
To enable this configuration, uncomment the following parameters in our schedulers-pools.conf file:
• org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores
• org.mule.runtime.scheduler.cpuLight.workQueue.size=0
• org.mule.runtime.scheduler.io.threadPool.coreSize=cores
• org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + mem - 245760) / 5120
• org.mule.runtime.scheduler.io.workQueue.size=0
• org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000
• org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores
• org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores

Example schedulers-pools.conf file:

• Issue
If we call a Java component from DW, that can lead us to performance issue.


• Explanation
Dataweaves ideally execute in CPU_INTENSIVE threads since they should be processed in a non-blocking fashion. And if the DataWeave component calls Java code, which can lead CPU_INTENSIVE threads becoming blocked for significant periods of time, because the underlying Java code is executed synchronously leading to these thread blocks.


• Solution 1
• Change the Java invoked by Java component instead of DW.
• Use Java module 1.2.5 or higher, which will support executing Java code in the BLOCKING_IO thread pool. 


• Solution 2
• Ideally DW component executes on CPU_INTENSIVE which has limited number of threads ( 2 thread per core).
• We can utilise BLOCKING_IO pool instead to CPU_INTENSIVE, which will help us to use more number of threads.
• Also, The BLOCKING_IO thread pool is better suited for blocking operations.
• To perform this change, the following argument must be passed to the JVM: 
  Dmule.dwScript.processingType=BLOCKING