2
votes

My flow looks like the below, I expect the message to be redelivered 2 times and then the

Redelivery is exhaused SAD

logger to be printed. But after the component throws the exception the re delivery mechanism does not kick in

Rollback with redelivery

<vm:connector name="VM" validateConnections="true" doc:name="VM" />


<flow name="TriggerFlow" >
    <http:listener config-ref="Orders_HTTP_Listener_Configuration" path="/rollback" allowedMethods="GET" doc:name="1080/rollback" />
    <vm:outbound-endpoint exchange-pattern="request-response" path="txFlow" doc:name="VM" connector-ref="VM" responseTimeout="60000">                      
    </vm:outbound-endpoint>
</flow>

<flow name="TxFlow" >
    <vm:inbound-endpoint exchange-pattern="request-response" path="txFlow" doc:name="case1" connector-ref="VM" responseTimeout="60000">
        <xa-transaction action="ALWAYS_BEGIN"/>
    </vm:inbound-endpoint>
    <scripting:component doc:name="Groovy">
        <scripting:script engine="Groovy"><![CDATA[throw new RuntimeException();]]></scripting:script>
    </scripting:component>
    <rollback-exception-strategy maxRedeliveryAttempts="3" doc:name="Rollback Exception Strategy">
        <logger message="Will rollback #[payload]" level="INFO" doc:name="Logger"/>
        <on-redelivery-attempts-exceeded>
            <logger message="Redelivery is exhaused SAD " level="INFO" doc:name="Logger"/>
        </on-redelivery-attempts-exceeded>
    </rollback-exception-strategy>
</flow>
1
I believe in order to work with rollback, the inbound end point should be transactional ( example JMS, WMQ). Here inbound is HTTP. In order to make your flow work, keep HTTP outbound endpoint ( Call your flow with same path) inside rollback after 'will rollback' logger. I have tried with VM transaction ( Not XA). It retried 3 times and exhausted as expected. Not sure mulesoft.org/documentation/display/35X/… they have mentioned rollback for HTTP endpoint, but couldn't see solid example.star

1 Answers

2
votes

I finally got the answer after speaking with MuleSoft. The updated flow should look like the below, both the VM's should be one-way and the processing strategy of the TxFlow should be synchronous. If the VM is request-reponse then it behaves more like a flow-ref with no queue involved and hence no redelivery ...

enter image description here