1

从 JMS 队列 (Websphere MQ) 中提取消息以使用 Mule (v. 2.2.1) 进行进一步处理时，我们会遇到虚假错误。下面我列出了受影响的服务以及 Mule 日志的摘录。第一段，“DispatchThread：1”，是服务按预期工作的情况，第二个，“DispatchThread：6”，消息丢失，即未处理。

如日志所示，消息作为事件排队等待 processFooBar.service 在这两种情况下处理，但在后一种情况下，它永远不会被提取以进行进一步处理。在工作示例中，它几乎立即出列并处理。

我们怀疑这是由于线程配置文件（即接收者线程配置文件等）的不平衡造成的，但同时我们认为这是一个非常模糊的解释。有点担心消息可能会丢失而无影无踪，即使我们增加线程数，如果系统负载增加，我们也可能会遇到同样的问题。

如果我们的怀疑能够得到证实，如果有人遇到同样的问题，我将不胜感激，他们对此做了什么？我们将升级到 Mule 3，但我怀疑这个问题对于 Mule 3 没有什么不同？

服务定义：

<service name="processFooBar">
    <inbound>
        <jms:inbound-endpoint queue="A.FROM.BAR"
                              connector-ref="fooConnector"
                              disableTemporaryReplyToDestinations="true">
            <transformers>
                <transformer ref="messageLogger"/>
                <transformer ref="jmsMessageToObjectTransformer"/>
                ...
                ..
            </transformers>
        </jms:inbound-endpoint>
    </inbound>
    ...
    ..
</service>

日志提取：

...
..
@ESB-: 2013-06-24 10:31:37,319 DEBUG [DispatchThread: 1] org.mule.service.AbstractService - Service: processFooBar has received asynchronous event on: jms://A.FROM.BAR
@ESB-: 2013-06-24 10:31:37,319 DEBUG [DispatchThread: 1] org.mule.model.seda.SedaService - Service: processFooBar has received asynchronous event on: jms://A.FROM.BAR
@ESB-: 2013-06-24 10:31:37,319 DEBUG [DispatchThread: 1] org.mule.model.seda.SedaService - Service processFooBar putting event on queue processFooBar.service: MuleEvent: ..., endpointEncoding=UTF-8}
@ESB-: 2013-06-24 10:31:37,321 DEBUG [processFooBar.1] org.mule.model.seda.SedaService - Service: processFooBar dequeued event on: jms://A.FROM.BAR
@ESB-: 2013-06-24 10:31:37,331 DEBUG [processFooBar.1] org.mule.model.seda.SedaService - Service processFooBar polling queue processFooBar.service, timeout = 10,000
@ESB-: 2013-06-24 10:31:37,339 DEBUG [processFooBar.2] org.mule.DefaultMuleMessage - new copy of message for Thread[processFooBar.2,5,main]
@ESB-: 2013-06-24 10:31:37,367 DEBUG [processFooBar.2] org.mule.transformer.AbstractTransformer - Setting transformer name to: fooDecoderTransformer
@ESB-: 2013-06-24 10:31:37,368 DEBUG [processFooBar.2] org.mule.transformer.AbstractTransformer - java.lang.Object has been added as source type for this transformer, there will be no source type checking performed
@ESB-: 2013-06-24 10:31:37,368 DEBUG [processFooBar.2] org.mule.transformer.AbstractTransformer - Setting transformer name to: objectToStringTransformer
...
..
@ESB-: 2013-06-24 13:19:51,896 DEBUG [DispatchThread: 6] org.mule.service.AbstractService - Service: processFooBar has received asynchronous event on: jms://FOMS.FROM.FSM.Bar
@ESB-: 2013-06-24 13:19:51,896 DEBUG [DispatchThread: 6] org.mule.model.seda.SedaService - Service: processFooBar has received asynchronous event on: jms://FOMS.FROM.FSM.Bar
@ESB-: 2013-06-24 13:19:51,897 DEBUG [DispatchThread: 6] org.mule.model.seda.SedaService - Service processFooBar putting event on queue processFooBar.service: MuleEvent: ..., endpointEncoding=UTF-8}
...
..
4

1 回答 1

0

Mule 的最大线程默认值为 16，因此您可以继续更改：

你能做的第一件事

  1. 在 JMS 连接器上设置 numberOfConsumers 属性
  2. 在 JMS 连接器的 receiver-threading-profile 元素上设置 maxThreadsActive 属性
<jms:activemq-connector name="jmsConnector" numberOfConsumers="15" brokerURL="vm://localhost">
    <receiver-threading-profile maxThreadsActive="15"/>
</jms:activemq-connector>

另一种解决方案是您可以设置流处理策略，请参考以下链接： https ://docs.mulesoft.com/mule-user-guide/v/3.5/flow-processing-strategies

于 2015-10-26T12:14:13.693 回答