Mule 的 jms:consume 和 jms:listener 的区别

Question

在本地使用 Mule 4.4 以及 Apache ActiveMQ。我正在尝试更好地理解 Mule 如何处理消息传递。

我尝试在互联网上搜索，但没有找到任何相关细节。

我有一个

jms:listener

:

<jms:listener doc:name="Listener" config-ref="JMS_Config" destination="Consumer.mine2.VirtualTopic.mine.test">
    <jms:consumer-type >
        <jms:queue-consumer />
    </jms:consumer-type>
</jms:listener>

我有一个

jms:consume

:

<jms:consume doc:name="Consume"  config-ref="JMS_Config" destination="Consumer.mine1.VirtualTopic.mine.test">
    <jms:consumer-type >
        <jms:queue-consumer />
    </jms:consumer-type>
</jms:consume>

对我来说，两者似乎都在做相同的工作，即使用队列/主题中的消息。那么为什么我们在 Mule 中有这两个组件呢？

Answer 1

jms listener

是一个源，因此使用它您可以在队列中有新消息时触发流程。

jms consume

是一种操作，因此您可以在流程执行中的任何位置使用它，即，就像放置在流程中间的

http request

组件一样。

它们都会消耗来自队列/主题的消息。但是，当您使用

listener

时，您基本上是在说“有一个队列，我不知道新消息何时会进来，但无论何时到来，我都需要执行这些操作”
当您使用

consume

操作时，您是在说“我很快就会收到一些消息，因此我将执行这些操作”。

现在在这两种情况下都可能根本没有消息，并且都有自己的处理方式。 A

listener

，因为它是一个源，所以不会简单地触发流程并继续等待。

consume

将阻止您的执行，直到出现消息为止，或者您可以配置超时以永远不会被阻止。

一个常见用例可以重新处理来自 DLQ 的消息。通常，当您使用队列时，您还会有一个 DLQ，以便可以将处理过程中失败的消息从“主”队列发送到 DLQ 并在稍后重新处理。
现在，在此架构中，您通常仅将

jms listener

与主队列一起使用来处理消息。您将拥有一个单独的流程，该流程可以具有

http listener

，以便您可以在准备好重新处理来自 DLQ 的消息时触发 HTTP 端点。此流程与

http listener

和

consume

来自 DLQ 的所有消息（可能在循环中）和

publish

它们返回主队列

Answer 2

提供了很好的解释。 只是想补充一点 JMS 侦听器在多工作人员场景中工作得非常好，但是 JMS 消费者仅在一个工作人员中工作，并在其他工作人员中超时。