It seems that using a session scoped variable to store the payload from a jms message queue creates a race condition especially when there are lots of messages on the queue. The race condition is happening at the transformer which transforms the message and saves it to a file. There is also a race condition occuring during saving the file as Mule reports a deadlock sometimes and throws an excpeption. However, when there is a ConnectException at a outbound http endpoint the message gets lost, it seems to be the only scope that could preserve the message for other flows.I am using private flows with a processingStrategy of synchronous but this doesn't solve the problem. Is there any other way apart from using a session scope variable to preserve the payload?

I used a flow variable to reset the payload in the exception strategy,right after the transformer. however the race condition still exists. I read in the book that a subflow ensures the same thread will process the request in the subflow as the parent flow. Is this what I need to do?

This is correct, a sub-flow will execute with the same thread as the caller flow.

Is this issue related to any example in the book?

The example I am using as a cookie cutter is based on chapter 2 which uses a subflow mule-in-action-2e-masterchapter02src est esourcessubflow.xml. In my case I also have a queue as the inbound endpoint of the main flow. My flow is very similar to the example except for the actions taken. Furthermore, my processing strategy is synchronous.

My flow is this:

Message arrives at jms endpoint
Put the message in a vm queue
Transform the input
Save the transformed message in case the following HTTP service is unavailable
Call a http service
if the http service returns a response other than 201 save to file
else if service is unavailable then save file to database

<custom-transformer name="myCustomTransformer"/>

<flow name="mainFlow" processingStrategy="synchronous">
<jms:inbound name="in.queue" ..../>
<vm:inbound-endpoint path="holder.in" />
<transformer-ref="myCustomTransformer"/>
<set-variable variableName="tempVar" value="#[message.payload]"/>
<http:oubound-enpoint address="some.address" />
<exception-strategy>
<!-- restore message to be saved in database -->
<set-payload value="#[flowVars.transformedMessage]/> <br /> <flow-ref name="subflow3">
</exception-strategy>
</flow>

<sub-flow name="subflow2">
<expression-filter expression="#[message.inboundProperties['http.status']!=201]]" />
<flow-ref name="subflow3" >
</sub-flow>

<sub-flow name="subflow3> <br /> <description> <br /> Save file to database. <br /> </description> <br /> </sub-flow> <br /> <br /> When there are already a lot of messages on the queue before my flow starts up, I experience a race condition. The transformer fails and sometimes to flowVars evaluation fails. I'm sure it is a race condition because the jaxb transform complains of a collision error. The database process also throws deadlock exceptions indicating mutliple threads. It seems that not the same thread from the parent flow processes the messages in the subflows, otherwise how would there be a race condition? I chose to use subflows instead of private flows for this reason but I am not seeing any benefits using the subflows.">

You can't have two inbound endpoints in a flow without wrapping them in a composite-source element. I'm surprised Mule even starts with a config like this one.

Or maybe the vm:inbound-endpoint should be a vm:outbound-endpoint?

Also subflow2 is not even called?

There is no doubt that the same thread is used for sub-flows, the race condition must come from something else, probably just from the concurrent consumers from the jms:inbound. If it's essential for this flow to process one JMS message at a time, you need to configure the JMS connector to use a single concurrent consumer.

Yes, you're right just a typo, the vm is an outbound endpoint. I will look into how to configure the jms inbound connector to use a single cosumer, if it is possible with this jms provider. I really appreciate your feedback, many thanks.

Yes, I have solved the problem. I was able to get access to the queue statistics and found there were four receivers registered with it I configured the connector to use 1 receiver and that eliminated the problem, thanks again, really appreciated.

Excellent, I'm glad you solved the issue!