The document explains the processing strategies used in Mule ESB, specifically synchronous and queued-asynchronous processing. It details how messages are handled within these strategies and outlines the limitations and specifications of non-blocking processing. Additionally, it provides guidance on how to configure processing strategies and mentions the default behavior if no strategy is defined.

1. Synchronous verses Asynchronous
Processing Strategy in Mule ESB

2. A flow process strategy determines however Mule implements the message process for a
given flow. All Mule flows have an implicit processing strategy that Mule applies
automatically: either synchronous or queued-asynchronous.
Even if you are doing not configure a processing strategy for your flow, the flow follows a
processing strategy automatically applied by Mule. The processing strategy can be:
Synchronous Flow Strategy : Mule processes messages during a single thread.

3. Queued-Asynchronous Flow Processing Strategy: Mule uses a
queue to decouple the receiver thread from the remainder of the flow.
The following table summarizes how Mule chooses a flow processing strategy:

4. Synchronous Flow Processing Strategy: This is used to process messages
in the same thread that originally received the message. Once the stream has received
a message, all processing, including processing the response, is done in this same
thread.

5. Non-Blocking Processing Strategy: This uses associate evented non-blocking
process models to process requests. one thread still handles each incoming request,
but non-blocking components return this thread to the listener thread pool. Only
upon obtaining and employing a new thread, can processing continue.
The following Non-Blocking strategy limitations:
• Only Message Source that supports non-blocking is that the HTTP Connector Listener.
• The only Message Processor that supports non-blocking is that the HTTP Connector
Request.
• Only Message Exchange Pattern presently supported is Request-Response.
• Only a limited set of components are fully supported to be used in non-blocking flows
Synchronous Fallback: If an unsupported component is configured during a flow
that's using the non-blocking processing strategy, then the flow reverts to the
synchronous processing from the purpose within the flow. There could also be
advanced cases where this is often desirable to require advantage of non-blocking for
a part of the flow, but typically it's best to stay with the synchronous processing
strategy.

6. Let's build a flow and specify a non-blocking processing strategy if the processing strategy
is not defined, the default flow will be the synchronous flow strategy

7. Choose the message flow and choose the appropriate processing strategy in the processing
strategy, as shown

8. The Ref option in the processing policy allows you to define the thread parameters and
escape behaviors of the pool.

9. Queued-Asynchronous Flow Processing Strategy: This uses a queue
to disassociate the stream receiver from the rest of the steps in the stream.

10. Test and verify the behavior

11. For More Information About
Mulesoft Online Training
VisualPath Training Institute
Address: Flat no:205, 2nd Floor,
Nilgiri Block, Aditya Enclave
Ameerpet, Hyderabad
Contact: +91 9989971070
Website:https://www.visualpath.in/

12. www.visualpath.in