Karthik
Karthik

Reputation: 91

Single point to point queue and multiple listeners

I have a single 'point to point' IBM MQ queue receiving messages from multiple producers. My application consumes the messages from the queue. I am using spring 'jmstemplate" and "DefaultMessageListenerContainer" to consume the messages asynchronously.

My application is running on 2 jvms, meaning there are 2 listeners active on each jvm listening to the same queue.

Coming to my questions, If a message arrives...

1) How does the listeners know that the message arrived in the queue?

2) Out of the two listeners, which one will receive the message ? What is the approach followed to distribute the messages to the listeners?

3) Can i scale to 'N' count of listeners for a singe queue? If i grow to 10 listeners, how does the scaling work? how are the messages distributed to listeners?

4) How does the MQ server make sure that the same message is not sent to multiple listeners?

May be these are simple questions, but not able to drill down on how the above scenarios works. Please share your thoughts...

Upvotes: 2

Views: 4961

Answers (1)

Gary Russell
Gary Russell

Reputation: 174494

  1. That's a function of the IBM client library; the listener container simply polls the JMS API waiting for a message; by default, it uses a 1 second receive timeout; with TRACE level logging, you will see log messages showing this activity. The timeout can be modified by setting receiveTimeout on the container.
  2. That is indeterminate from the client's perspective; the IBM broker knows how many consumers are registered and picks one. Some brokers allow configuration of a pre-fetch; this can help performance under high volume but can hurt performance under low volume.
  3. Yes; the Spring Listener Container can dynamically scale the listeners based on load; you can configure min/max consumers and Spring will adjust within those bounds as necessary. Each listener is a separate consumer, as far as the broker is concerned so the work is distributed according to the broker's algorithms.
  4. That's a function of the IBM broker (and part of the JMS contract).

If using transactions and a message is rolled back onto the queue; there is no guarantee that the same listener will get the re-delivered message.

Upvotes: 5

Related Questions