To opt benefits of asynchronous processes, MuleSoft has introduced thread management which has no dependency on the configuration. It works based on available resources on platforms.

MuleSoft follows and recommends an asynchronous process hence came with an event-based approach along with an asynchronous approach. It allows the application to be more responsive by not waiting for long processes like your I/O processes to finish.

Below is a major difference to follow event-based (Reactive Programming) pattern:

• Reactive Programming — Focusing on computation through ephemeral data streams, tend to be event-driven.
• Messages have a unique clear destination, while Events are made for others to observe.

With definition**:**

Reactive Systems: Defined by the Reactive Manifesto — is a set of architectural design principles for building modern systems that are well prepared to meet the increasing demands that applications face today.

**Proactor Pattern: **A fully asynchronous design pattern made for handling events. It’s very much like multi-threaded programming, without the need for you to think of thread management.

• Pros and Cons (Proactor Pattern)
• The obvious benefit is the asynchronous execution. As mentioned, it allows the application to be more responsive by not waiting for long processes like your I/O processes to finish. Also, with a centralized thread pooling and dispatching mechanism, there is no need for the user of the Proactor implementation to deal with thread management directly. The implementation can be further improved so that the thread pool can grow and shrink dynamically based on the available physical resources and the number of pending tasks. Tasks can also be made to queue based on priority.
• As for the downsides, like many asynchronous or multi-threaded paradigms, debugging can be quite a hassle. Although usually not needed, you may have to consider thread synchronization when multiple tasks use a shared resource (and this increases the risk of getting deadlocks, starving away your thread pool). For a small application, I feel that the Proactor pattern may add unnecessary complexity to the overall architecture.

**Reactive Programming: **It has a major benefit in event-driven programming… as follows:

It is the flow of data rather than the flow of control;

• This is information that drives the logic forward rather than having control flow driven by a thread-of-execution.
• It supports decomposing to execute an asynchronous and non-blocking fashion.
• Allows for non-blocking execution.

The Benefits (And Limitations) Of Reactive Programming;

• Increased utilization of computing resources on multi-core and multi-CPU hardware and increased performance by reducing serialization points.
• Developer productivity as a straightforward and maintainable approach to dealing with asynchronous and non-blocking computation and IO.
• Inclusion of back-pressure is crucial to avoid over-utilization or rather unbounded consumption of resources

The primary benefits of Reactive Programming are:

• Increased utilization of computing resources on multi-core and multi-CPU hardware; and increased performance by reducing serialization points.
• Developer productivity as a straightforward and maintainable approach to dealing with asynchronous and non-blocking computation and IO.
• Inclusion of back-pressure is crucial to avoid over-utilization or rather unbounded consumption of resources

MuleSoft Threads — Uber vs. Dedicated

MuleSoft introduced an approach to self manages approach for thread availability and executions. In the current release, MuleSoft has two major thread pooling approach as below.

UBER: It is a unified scheduling strategy to manage threads and its allocation to process events. All individual thread pool (cpu_light, cpu_intensive, and I/O) backed by Uber thread pool. In Uber, type of threads same as previous processes, it only follows an algorithm to support the optimum performance of threads in processing.

DEDICATED: It is a self thread managed thread pool and allocates based on component process requirements.

NOTE: Both approaches follow the strategy to best utilization of thread management in Mulesoft runtime. This strategy works on existing threads (cpu_light, cpu_intensive, and I/O).

Recommended: Always run mule using the UBER strategy.

#microservices #mulesoft #reactive programming #mule 4 #reactive system #proactor pattern