Mule provides several threading models and strategies for processing messages: - SEDA decomposes applications into stages connected by queues to improve parallelism. - Thread pools are configured based on exchange patterns, processors, transactions, and processing strategies. - Asynchronous processing uses receiver threads to queue messages and flow threads to process them in parallel, improving throughput.

1. Mule Threading Management
• SEDA
• Thread pools
• Tuning Threading Profile
• Processing Strategy
• Async scope

2. SEDA(staged event-driven architecture)
• decomposes a complex, event-driven application into a set of stages
connected by queues

4. Factors that determine Thread Pool
• Configured exchange pattern
• Outbound message processor
• Transaction
• Processing strategy

5. If you are using synchronous processing, the same thread is used to carry
the message all the way through Mule. As the message is processed, if it
needs to be sent to an outbound endpoint, one of the following applies:
• If the outbound endpoint is one-way, the message is sent using the same
thread. Once it has been sent, the thread resumes processing the same
message. It does not wait for the message to be received by the remote
endpoint.
• If the outbound endpoint is request-response, the flow thread sends the
message to the outbound endpoint and waits for the response. When the
response arrives, the flow threads resumes by processing the response.

6. If you are doing asynchronous processing, the receiver thread is used only to
place the message on a staged event-driven architectur (SEDA) queue, at
which point the message is transferred to a flow thread, and the receiver
thread is released back into the receiver thread pool so it can carry another
message. As the message is processed, if it needs to be sent to an outbound
endpoint, one of the following applies:
• If the outbound endpoint is one-way, the message is copied and the copy
processed by a dispatcher thread, while the flow thread continues
processing the original message in parallel.
• If the outbound endpoint is request-response, the flow thread sends the
message to the outbound endpoint and waits for the response. When the
response arrives, the flow threads resumes by processing the response.

7. Scenario 1-Fully SEDA architecture
• Inbound connector is one-way
• Outbound connector is one-way
• No transactional flow

8. Scenario 2- synchronous-asynchronous mode
• Receiver Thread is exchange-pattern
• Dispacher Thread is one-way

9. Scenario 3- Fully synchronous mode

10. Scenario 4 - asynchronous-synchronous mode

11. How to implement own SEDA
• Mule’s VM transport is an excellent mechanism to help break your
flows into smaller, composite flows that are decoupled with in-
memory queueing. This allows you to realize the benefits of SEDA at
the macro level, breaking your application into smaller flows that can
be individually tuned and are decoupled with VM queueing.

12. Tuning threading profile
• Configuration level
• Connector level
• Flow level

13. Default Threading profile
• <configuration>
• <default-threading-profile
• maxBufferSize="100" maxThreadsActive="20"
• maxThreadsIdle="10" threadTTL="60000"
• poolExhaustedAction="ABORT" />
• </configuration>

14. Processing Strategy
• default queued asynchronous
• Synchronous-thread-per-processor-processing-strategy
• queued-thread-per-processor-processing-strategy
• thread-per-processor-processing-strategy (with cores)