您的位置: 首页  >  技术问答  >  超过了JMS Mule max重新交付

超过了JMS Mule max重新交付

分类: 技术问答 • 2022-04-29 16:16:16
问题描述：

我有一个非常简单的设置，用于从HornetQ队列中读取MULE并将对象保存到数据库:

I have very simple setup of MULE reading from the HornetQ queue and saving Object to database:

以下设置:

<jms:connector name="connector.jms" maxRedelivery="1" connectionFactory-ref="hornetQConnectionFactory" doc:name="JMS"
        createMultipleTransactedReceivers="true"
        numberOfConcurrentTransactedReceivers="100"
        acknowledgementMode="AUTO_ACKNOWLEDGE">
    <reconnect count="50" frequency="5000"/>       
</jms:connector>
<flow name="jmsListenerFlow1" doc:name="jmsListenerFlow1">
    <jms:inbound-endpoint queue="adsLogQueue" connector-ref="connector.jms" doc:name="JMS">
        <jms:transaction action="ALWAYS_BEGIN"/>
    </jms:inbound-endpoint>
    <component >
        <spring-object bean="logSaver"/>
    </component>

</flow>

为什么当maxRedelivery设置为1时，我收到一条消息，该消息已在端点上重新发送了9次?到底是什么意思?

Why do I get a message that message has been redelivered 9 times on endpoint while maxRedelivery setting is 1 ? What does it exactly mean ?

hornetQConnectionFactory:

hornetQConnectionFactory:

        <bean name="hornetQTransportConfiguration" class="org.hornetq.api.core.TransportConfiguration">
        <constructor-arg value="org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"/>
        <constructor-arg>
            <map>
                <entry key="host" value="${jms.host}" /> 
                <entry key="port" value="${jms.port}" /> 
            </map>
        </constructor-arg>

    </bean>
    <bean name="hornetQConnectionFactory" class="org.hornetq.jms.client.HornetQJMSConnectionFactory">
        <constructor-arg index="0" value="false"/>
        <constructor-arg index="1" ref="hornetQTransportConfiguration"/>
        <property name="minLargeMessageSize" value="250000"/>
        <property name="cacheLargeMessagesClient" value="false"/>
    </bean>

任何帮助将不胜感激！

下面的堆栈跟踪.


ERROR 2012-10-19 01:04:07,283 [Thread-3013 (HornetQ-client-global-threads-1442093417)]: 

Message               : "Message with id "ID:e6a0b303-1977-11e2-96d4-810571a3fe10" has been redelivered 9 times on endpoint "jms://adsLogQueue", which exceeds the maxRedelivery setting of 1 on the connector "connector.jms". Message payload is of type: HornetQObjectMessage
Code                  : MULE_ERROR--2

Exception stack is:
1. "Message with id "ID:e6a0b303-1977-11e2-96d4-810571a3fe10" has been redelivered 9 times on endpoint "jms://adsLogQueue", which exceeds the maxRedelivery setting of 1 on the connector "connector.jms". Message payload is of type: HornetQObjectMessage (org.mule.transport.jms.redelivery.MessageRedeliveredException)
  org.mule.transport.jms.redelivery.JmsXRedeliveryHandler:91 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/transport/jms/redelivery/MessageRedeliveredException.html)

Root Exception stack trace:
org.mule.transport.jms.redelivery.MessageRedeliveredException: "Message with id "ID:e6a0b303-1977-11e2-96d4-810571a3fe10" has been redelivered 9 times on endpoint "jms://adsLogQueue", which exceeds the maxRedelivery setting of 1 on the connector "connector.jms". Message payload is of type: HornetQObjectMessage
    at org.mule.transport.jms.redelivery.JmsXRedeliveryHandler.handleRedelivery(JmsXRedeliveryHandler.java:91)
    at org.mule.transport.jms.MultiConsumerJmsMessageReceiver$JmsWorker.preProcessMessage(MultiConsumerJmsMessageReceiver.java:418)
    at org.mule.transport.AbstractReceiverWorker$1$1.process(AbstractReceiverWorker.java:120)
    + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
********************************************************************************

答

首先要注意的是Mule使用的是JmsXRedeliveryHandler，这意味着它检测到HornetQ支持JMS_X_DELIVERY_COUNT标头，并将进行计数重新交付.在这种情况下，Mule完全依靠HornetQ来提供准确的重新交付数量.

The first thing to note is that Mule is using JmsXRedeliveryHandler, which means it has detected that HornetQ supports the JMS_X_DELIVERY_COUNT header and will take care of counting the re-deliveries. In that situation, Mule fully relies on HornetQ for providing an accurate count of re-deliveries.

抛出此异常的事实意味着，已向Mule提交了一条JMS消息，其重新交付计数超过了JMS连接器上配置的计数(在您的情况下为1).

The fact this exception is thrown means that a JMS message has been presented to Mule with a redelivery count that exceeds the count configured on the JMS connector (1 in your case).

由于您消耗了一笔交易，除非您已在HornetQ本身上配置了最大的重新发送计数，否则每次重新启动时，HornetQ都会回滚并将此消息表示给Mule，这很可能会发生.

Since you consume in a transaction, what's likely to happen is that HornetQ will rollback and represent this message to Mule, on each restart, again and again unless you've configured a maximum redelivery count on HornetQ itself.

我的建议是:在Mule和HornetQ上设置相同的重新交付计数，或者在Mule上使用-1(无限制)，并完全依靠HornetQ的重新交付限制.

My advice is: set the same redelivery count on Mule and HornetQ or use -1 on Mule (no limit) and fully rely on HornetQ's redelivery limit.

相关推荐