Mule ESB：“Jms 会话应该被处理”是什么意思？答案

【问题标题】：Mule ESB: What "Jms session should be transacted" means?Mule ESB：“Jms 会话应该被处理”是什么意思？
【发布时间】：2016-03-18 02:03:25
【问题描述】：

快速，直截了当

我正在 JMS 订阅流程中测试重试逻辑。它在扔

org.mule.transaction.IllegalTransactionStateException: Jms session should be transacted

正在使用 JMS ActiveMQ 的管理界面 (localhost:8161/admin/topic) 进行测试，向主题 [流程正在订阅] 发送消息。

问题：

是否由于某些原因而引发错误？配置正确吗？或者
默认情况下，使用 ActiveMQ 的“发送至”提交消息是非交易会话？如何使其“交易”？

详细的 [和更长的] 解释

流具有作为消息源的 JMS 端点（设置为持久客户端）；另外，流程配置为“多资源事务”类型；并有一个“回滚异常策略”。该流程已被有意配置为引发 SQL 错误（在主键列中插入固定值），并记录“回滚异常策略”消息。

以下是流程：

--EDIT: 以及 JMS 连接配置

...
    <jms:activemq-connector name="PasswordResetTuT_Durable_Client_ACK_MQ" brokerURL="tcp://localhost:61616?keepAlive=true" validateConnections="true" clientId="PASSWORDRESET" doc:name="Active MQ" durable="true" maxRedelivery="5" >
        <reconnect frequency="7000" count="30"/>
    </jms:activemq-connector>
...
    <flow name="PASSWORDRESET-TUT.RequestConfirmation" processingStrategy="synchronous">
        <jms:inbound-endpoint topic="/passwordreset-tut/requestConfirmation" connector-ref="PasswordResetTuT_Durable_Client_ACK_MQ" durableName="PASSWORDRESET-TUT.RequestConfirmationDurableClientName" doc:name="JMS">
            <ee:multi-transaction action="ALWAYS_BEGIN" timeout="15000"/>
        </jms:inbound-endpoint>
        <!-- ...
                some processing goes here ...
                                              -->
        <expression-component doc:name="Expression"><![CDATA[flowVars.token="123456789ABCDEF";]]></expression-component>
        <db:insert config-ref="PasswordReset_Database_Configuration" doc:name="Insert into TOKEN">
            <db:parameterized-query>
                <!-- an insert statement that, due to the 
                     expression-component above, will attempt to 
                     insert a duplicate value into a primary key -->
            </db:parameterized-query>
        </db:insert>
        <!-- ...
                some processing goes here ...
                                              -->
        <logger message="Finished confirming #[flowVars.token]." level="INFO" doc:name="Logger"/>
        <rollback-exception-strategy maxRedeliveryAttempts="5" doc:name="Rollback Exception Strategy">
            <logger message="Exception throw. Attempting redelivery #[(message.inboundProperties.JMSRedelivered==false)?1:message.inboundProperties.JMSXDeliveryCount+1] for message #[message.outboundAttachments.JMSMessageID]." level="INFO" doc:name="Logger"/>
            <on-redelivery-attempts-exceeded>
                <logger message="Redelivery exhausted. Sending #[message.inboundProperties.JMSMessageID] to DLQ." level="INFO" doc:name="Logger"/>
                <jms:outbound-endpoint topic="/passwordreset-tut/DLQ/requestConfirmation" connector-ref="PasswordResetTut_MQ" doc:name="JMS"/>
            </on-redelivery-attempts-exceeded>
        </rollback-exception-strategy>
    </flow>
...

第一次“测试尝试”是使用 ActiveMQ 的“发送至”[主题]（http://localhost:8161/admin/topics.jsp）完成的：它引发了上述错误。

现在，尚不清楚（至少对我而言）是 (1) 问题是由我用来测试此问题的方法引起的，还是 (2) 是由于某些错误配置引起的 [在流程中].

【问题讨论】：

添加PasswordResetTuT_Durable_Client_ACK_MQ 的配置可能会有所帮助
@Petter：PasswordResetTuT_Durable_Client_ACK_MQ 的配置已添加到文本中。感谢您提出这个问题。

标签： error-handling mule esb rollback

【解决方案1】：

我认为这可能与需要为 ActiveMQ 连接器设置事务类型有关，如果您有重试策略，它必须是一个事务，以便事务被保存并可以重试。从消息流中，如果单击 JMS 连接器，您应该会在队列和主题设置下方看到事务设置。对于所有入站 JMS，应将其设置为始终开始，对于任何遵循 JMS 入站的出站，应将其设置为始终加入。

【讨论】：