One of the things that I believe is slightly complicated in Mule is the behaviour of private flows.
Wait… is there a difference between private flows and sub-flows?
Well there is, and if you are not aware of it, it might bite you very badly. Let’s start from the easiest behaviour; sub-flows.
Flow-ref to sub-flow behaves just like method calls. It is always performed in synchronous mode, which means the caller waits for the sub-flow to finish, and then it’s executed by the same thread. The payload returned by the sub-flow will replace that of the original caller on return. This behaviour is always consistent, irrelevant of any other settings.
Private flows behave in the same way ONLY if at least one of the following conditions are met:
- The calling flow is synchronous
- The private flow’s processing strategy is explicitly set to synchronous
If the above conditions are not met, the flow-ref to the private flow behaves the same way as if the flow-ref was placed in an async block. Hence, the caller does not wait for the private flow to finish, and the result of the private flow does not affect the payload of the calling flow. Furthermore, the private flow is executed in its own separate thread.
Here are a few examples to illustrate this behaviour. Mule 3.5.0 was used for these tests. We start with a main flow having an HTTP request-response inbound endpoint, which forces synchronous behaviour. This flow makes two calls using flow-ref; to a sub-flow and to a private flow.
You can see the behaviour in the following logs. All calls to the logger were executed by the same thread, and the final result of the private flow replaced the main flow’s payload.
If we simply change the inbound endpoint from request-response to one-way, the behaviour changes as you can see in the following log file.
As shown, the private flow execution was carried out by a separate thread, and it did not affect the main flow’s payload.
If we set the processing strategy on the private flow to synchronous and leave the inbound endpoint as one-way (shown below), we get the original behaviour as seen in the following logs.
I hope you enjoyed this blog post.
This blog post 1st published; 8th July 2014 on blog.ricston.com