Mule请求响应VM的回滚异常策略 [英] Roll back exception strategy for Mule request response VM

查看:137
本文介绍了Mule请求响应VM的回滚异常策略的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用m子请求响应VM,并且在发生某些异常(例如连接问题)的情况下,需要VM重新处理回滚消息.但是,当我使用交换模式作为VM的请求响应时,回滚异常策略似乎不起作用.我使用请求响应的原因是我需要知道所有VM消息何时已处理并在此之后启动另一个任务的方法.我认为行为是当发生异常时,回滚策略会捕获异常并可能将其提交.我看不到尝试将消息重新传递回VM的情况.当交换模式为单向时,它确实很好用.

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>

推荐答案

是的,我遇到了类似的问题,当VM出站使用请求-响应交换模式时,其行为更像是流引用,而没有涉及队列"说,因此没有重新交付机制.

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.

因此,如果将VM配置为单向且流处理策略是同步的(VM入站流),则重新交付确实会开始.

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.

要实现您想要的目标,可以使用直到成功 vmtransactionrollbackFlow1流中的范围,尤其是对于间歇性连接丢失的情况,这实际上是推荐的方法.在其中您根本不需要交易.

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.

这篇关于Mule请求响应VM的回滚异常策略的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆