CODEWITHSUNDEEP
jmsmule4
GettingStarted With123
GettingStarted With123

Reputation: 427

Difference between Mule's jms:consume and jms:listener

Using Mule 4.4 on premise along with Apache ActiveMQ. I am trying to get a better understanding of how Mule handles messaging.

I tried searching the internet but am not finding any details about the same.

I have a 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>

and I have a 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>

To me both seem to be doing the same job i.e. consume messages from a queue / topic. So why do we have these two components in Mule?

Upvotes: 0

Views: 717

Answers (1)

Harshank Bansal
Harshank Bansal

Reputation: 3261

jms listener is a source, so using it you can trigger a flow whenever there is a new message in queue.
enter image description here

jms consume is an operation, so you can use it anywhere within a flow's execution, i.e. like a http request component that you put in the middle of a flow. enter image description here

Both of them will consume a message from the queue/topic. However, when you are using a listener you are basically saying that "There is a queue, I do not know when a new message will come in, but whenever it comes I need to perform these actions"
When you use a consume operation, you are saying "I am expecting some message soon and with that I will to these actions".

Now in both cases a message may not come at all, and both have there own way to deal with it. A listener, since it is a source, will just not simply trigger the flow and keep on waiting. A consume will block your execution until a message is there, or you can configure a time out to not be blocked fore ever.

A common use case can be reprocessing messages from a DLQ. Generally when you use a queue, you also have a DLQ so that the messages that failed during processing, from the "main" queue, can be sent to the DLQ and reprocessed later.
Now, in this architecture, you will typically use the jms listener only with the main queue for the processing of the messages. And you will have a separate flow that can have a http listener so that you can trigger an HTTP Endpoint whenever you are ready to reprocess the messages from the DLQ. This flow with http listener with consume all the messages (probably in a loop) from the DLQ and publish them back to the main queue

Upvotes: 2

Related Questions