Roll back exception strategy for Mule request response VM - exception

Question

I am using mule request response VM and need the rollback messages to be reprocessed by VM in case of some exceptions, say connection issues. However, the rollback exception strategy does not appear to work when I use exchange pattern as request response for VM. The reason I used request response is I need way to know when all my VM messages have been processed and initiate another task after that. I think the behavior is that when there is an exception, the rollback strategy catches the exception and probably commits it. I do not see it trying the redeliver the message back to VM. It does work good when the exchange pattern is one-way.
<flow name="vmtransactionrollbackFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/myvm" doc:name="HTTP"/>
<set-payload value="Dummy list payload" doc:name="Set Payload"/>
<foreach doc:name="For Each">
<vm:outbound-endpoint exchange-pattern="request-response" path="myvm" connector-ref="VM" doc:name="VM">
<vm:transaction action="ALWAYS_BEGIN"/>
</vm:outbound-endpoint>
</foreach>
<logger message="DO SOMETHING ONLY AFTER ALL MESSAGES IN VM ARE PROCESSED" level="INFO" doc:name="Logger"/>
</flow>
<flow name="vmtransactionrollbackFlow1">
<vm:inbound-endpoint exchange-pattern="request-response" path="myvm" connector-ref="VM" doc:name="VM">
<vm:transaction action="BEGIN_OR_JOIN"/>
</vm:inbound-endpoint>
<scripting:component doc:name="Groovy">
<scripting:script engine="Groovy"><![CDATA[throw new java.lang.Exception("Test exception");]]></scripting:script>
</scripting:component>
<rollback-exception-strategy maxRedeliveryAttempts="3" doc:name="Rollback Exception Strategy">
<logger message="Rolling back #[payload]" level="INFO" doc:name="Logger"/>
<on-redelivery-attempts-exceeded>
<logger message="Redelivery exhausted:#[payload]" level="INFO" doc:name="Logger"/>
</on-redelivery-attempts-exceeded>
</rollback-exception-strategy>
</flow>

Answer 1

Yes I ran into a similar problem, when the VM outbound uses a request-response exchange pattern it behaves more like flow-ref with no "queue" involved per say and hence no redelivery mechanism.
So if the VM's are configured as one-way and the flow processing strategy is synchronous (VM inbound flow), then the redelivery does kick in.
To achieve what you want you could use until-successful scope within the vmtransactionrollbackFlow1 flow, especially for the case of intermittent connection losses this is actually the recommended approach. In which you do not need transactions at all.
Do let us know how it goes, and if you found some other work around.