Flow Processing Strategies in Mule3

« Flow Processing Strategies »

A flow processing strategy determines how Mule implements message processing for a given flow.

Should the message be processedsynchronously (on the same thread) or asynchronously (on a different thread)?
If asynchronously, what are the properties of the pool of threads used to process the messages?
If asynchronously, how do messages wait for their turn to be processed in the second thread?
Should the message be Non-Blocking Processing Strategy? (Available in Mule 3.7 and newer)

How Mule choose a Flow Processing Strategy

Mule selects a processing strategy for a flow based on two criteria:

The flow’s exchange pattern.
Whether or not the flow is transactional.

A flow employs one of two exchange patterns, determined by the exchange pattern of the flow’s inbound endpoint:

A request-response exchange pattern is used when the sender of the messages, such as the flow’s inbound endpoint expects a response or some kind of result to return to the caller.
A one-way exchange pattern is used when no response is expected, or when the result is sent to some other flow or system and not back to the caller.

The following table summarises how Mule chooses a flow processing strategy:

Exchange Pattern	Transactional?	Flow Processing Strategy
Request-Response	Yes	Synchronous
Request-Response	No	Synchronous
One-way	Yes	Synchronous
One-way	No	Queued-Asynchronous

Can we change Processing Strategy?

Below table will explain whether we can change a default processing strategy or not :

Flow Processing Strategy implictly applied by Mule	Can we specify a different processing strategy?	Can we fine-tune the processing strategy?	Can you create a processing block that executes using a different processing strategy from the main flow?	Can you apply a custom processing strategy using Spring?
Synchronous	No	No	Yes	Yes
Queued-Asynchronous	Yes	Yes	Yes	Yes

Implicit Processing Strategies

Even if we do not configure a processing strategy for your flow, the flow follows a processing strategy automatically applied by Mule.

For the majority of use cases, the implicit strategy selected by Mule is optimal.

The processing strategy can be:

Synchronous Flow Processing Strategy : Mule processes messages in a single thread.
Queued-Asynchronous Flow Processing Strategy : Mule uses a queue to decouple the receiver thread from the rest of the flow.

Synchronous Flow Processing Strategy

The synchronous approach is used to process messages in the same thread that initially received the message.

The synchronous strategy is ideally suited to flows where:

The sender of the message expects a response. This is known as a "request-response" exchange pattern.
All the steps in the flow are considered a single unit, which must succeed entirely or fail entirely.
The flow’s inbound endpoint must be notified of all errors that occur during the processing of the message.

Queued-Asynchronous Flow Processing Strategy

The queued-asynchronous approach uses a queue to decouple the flow’s receiver from the rest of the steps in the flow.

This means that once the receiver places a message into a queue, it can immediately return and accept a new incoming message.

Furthermore, each message waiting in the queue can be assigned a different thread from a pool of threads.

The specific type of queue implemented for the queued-asynchronous flow processing strategy is known as a SEDA queue.

Specify a Processing Strategy

The procedure to change a processing strategy for an individual flow is straightforward.

We may only specify a processing strategy for flows to which Mule would implicitly apply a queued-asynchronous processing strategy.

The most frequent use case for specifying a processing strategy is to force a flow that would otherwise be queued-asynchronous to be synchronous instead.

To force a flow to be synchronous, add the processingStrategy attribute to the flow that you want to change and set it to synchronous.

This is illustrated in the code example below.

The table below lists the processing strategy names, which can each be declared as values for the processingStrategy attribute, or as a global element.

Additional Asynchronous Processing Strategy Element/Global Element Names	Description
asynchronous-processing-strategy	Not applicable to most use cases.Same as queued-asynchronous processing strategy except that it doesn’t use a queue.
queued-thread-per-processor-processing-strategy	Not applicable to most use cases.Writes messages to a queue, then every processor in the scope runs sequentially in a different thread.
thread-per-processor-processing-strategy	Not applicable to most use cases.Every processor in the scope runs sequentially in a different thread.

Create an Asynchronous Processing Block

If Mule has applied a synchronous processing strategy to a flow, we can separate out a processing block that executes simultaneously with the main flow and does not return messages back to the main flow.

Achieve this in one of two ways:

Wrap one or more processors in an async scope.
Create an asynchronous flow by wrapping a flow-ref element in an async scope. So that the contents of the flow will be processed asynchronously with the triggering flow.

Both of these methods allow you to block off a set of processing steps that may be very time consuming to execute.

Because this asynchronous processing block is one-way, the main flow does not wait for a response and is free to continue processing in the main thread.
If no processing strategy is configured for the async scope, Mule applies a queued-asynchronous processing strategy.

The following global elements are available for configuring the processing strategy of an asynchronous scope.

Global Element	Description
asynchronous-processing-strategy	Not applicable to most use cases.Same as queued-asynchronous processing strategy except that it doesn’t use a queue.
queued-asynchronous-processing-strategy	Uses a queue to decouple the flow’s receiver from the rest of the steps in the flow.Select this if you want to fine-tune this processing strategy by: Changing the number of threads available to the flow. Limiting the number of messages that can be queued. Specifying a queue store to persist data.
queued-thread-per-processor-processing-strategy	Not applicable to most use cases.Writes messages to a queue, then every processor in the scope runs sequentially in a different thread.
thread-per-processor-processing-strategy	Not applicable to most use cases.Every processor in the scope runs sequentially in a different thread.

What is Non-Blocking Processing Strategy

In this model a single thread still handles each incoming request, but non-blocking components return this thread to the listener thread pool.

Only upon obtaining and using a new thread, can processing continue.

In this example, the HTTP components support Non-Blocking I/O (NIO). This means that:

The HTTP Request processor internally doesn’t need a thread to wait for a response, but rather receives an event when the response is available.
The HTTP Listener message source can send the client response using any thread when the response is ready.

The thread usage can be explained as followed.

The request is handled by a listener thread as with the synchronous processing strategy.
Given the HTTP Request processor supports non-blocking, it frees up the listener thread once the request is sent.
No threads are in use between sending the HTTP request and receiving the HTTP response.
Once a response is available, the HTTP Request process obtains a new thread to continue processing from the Flow thread pool.
Processing then continues using the flow thread and the same happens whenever a non-blocking processor is encountered
Finally, the HTTP Listener response is sent back using whichever thread is currently processing the flow, in this case it is a flow thread.

The main advantage of Non-Blocking processing-strategy is that in a flow that uses this processing strategy, as long as the flow doesn’t block for I/O or use Thread.sleep() anywhere, no tuning is required to achieve optimum performance.