Mule 请求响应 VM 的回滚异常策略

Roll back exception strategy for Mule request response VM

我正在使用 mule 请求响应 VM,并且需要 VM 重新处理回滚消息以防出现某些异常,比如连接问题。但是,当我使用交换模式作为 VM 的请求响应时,回滚异常策略似乎不起作用。我使用请求响应的原因是我需要知道何时处理了我的所有 VM 消息并在此之后启动另一个任务。我认为行为是当出现异常时,回滚策略捕获异常并可能提交它。我没有看到它尝试将消息重新传送回 VM。当交换模式是单向时,它确实工作得很好。

     <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>

是的,我 运行 遇到了类似的问题,当 VM 出站使用请求-响应交换模式时,它的行为更像 flow-ref,每个 say 不涉及 "queue",因此没有重新传递机制.

因此,如果 VM 配置为单向且流处理策略是同步的(VM 入站流),则重新传送会启动。

要实现您想要的效果,您可以在 vmt运行sactionrollbackFlow1 流程中使用 until-successful 范围,特别是对于间歇性连接丢失的情况,这实际上是推荐的方法。其中您根本不需要 t运行sactions。

请告诉我们进展如何,以及您是否找到其他解决方法。