Multiple listeners on a queue

[Satya Maheshwari]

Hi
Is it possible to have multiple listeners on a queue? For e.g. consider a scenario where tasks get collected in a queue and multiple workers keep on reading tasks from the queue and work on them. When I tried to do this on jboss, after registering more than one listener on a queue, the act of sending a task to the queue simply hangs and nothing happens. Will greatly appreciate your help.

[Luciano A. Pozzo]

Satya,

I believe that you should use a 'topic' for this situation. From what I know, a message of the queue could be consumed only once. So, I guess that it's possible have more than one listener registered, but only one will consume (and remove the message from the queue).

[aleem khan]

Ofcourse you can have multiple listeners on a queue , that is the job of messaging service..
have multiple listeners on queue or topic and read from them whenever message arrives.
You may want to post the complete code and stack trace along with configuration files ,some one
can suggest you

[aleem khan]

From pg 115 (EJB3 In Action)
PTP message destinations are called queues. Note
that PTP doesn’t guarantee that messages are delivered in any particular order—
the term queue is more symbolic than anything else. Also, if more than one potential
receiver exists for a message, a random receiver is chosen, as figure 4.4 shows.


You can have multiple receivers but only one will be selected (in random), so if you
want all the receivers should receive message then use topic as already it has been
suggested

[Jimmy Clark]

Is it possible to have multiple listeners on a queue?

There are two basic message models.

The term "message queue" applies to the Point-to-Point (PTP) message model. Here a message is delivered to a destination, known as a queue. And messages are sent on a one-to-one basis, i.e. a single sender and a single receiver.

In the Publish/Subscribe message model, the term "queue" is not used. Here a message is published to a topic. One or more publishers can publish messages to the same topic. One or more client applications can subscribe to a topic.

So, a "queue" should not have multiple listeners, only one.

[Paul Clapham]

James Clark wrote:So, a "queue" should not have multiple listeners, only one.

In the past I have run two (identical) listeners to clear up a backlog on a JMS queue. That didn't seem wrong to me, but all I know about JMS came from an old Sun tutorial. Was that not a legitimate thing to do?

[Jimmy Clark]

In the past I have run two (identical) listeners to clear up a backlog on a JMS queue.

Did you consider "clearing up a backlog" as part of the normal design or was this some remedy to fix a problem/issue? Did you create the application with two listeners or did you add the second listener at a latter point in time? Did you leave the 2nd listener in the production system or was the 2nd listener removed?

[aleem khan]

Hi James
-----------------------------------------------------------------
So, a "queue" should not have multiple listeners, only one.
------------------------------------------------------------------

As per EJB3 In Action book , queue can have multiple listeners but only one will be selected randomly
so i think you can have (it will not throw error) but only one listener will receive message.
Let me know if i am wrong

[Jerwin Louise Uy]

If you have business rules in selecting the messages where multiple listeners are interested, then you can use message filtering so that the provider can select the appropriate listener.

If you simply want to decorate the primary listener, then you can achieve this by using an interceptor.

Regards.

[Jimmy Clark]

... queue can have multiple listeners but only one will be selected randomly
so i think you can have (it will not throw error) but only one listener will receive message.
Let me know if i am wrong

There are a few differences between what "can" be done and "efficient" software design. There are many, many things that can be done and are described in detail in technical documentation. There is nothing wrong with this as authors write in different contexts. It is up to the reader to decipher and understand the material. A shrewd software designer will be able to read what "can" be done and will make decisions that best meet the technical requirements and QoS requirements, e.g. maintainability, scaleability, reliability, etc.

That said. The PTP message model has one sender and one receiver. From a functional perspective, when designing the communication between applications, multiple listeners that are connected to different types of receiver applications is a conflict with the PTP model, in my opinion. Even if it can be coded and compiled. The appropriate message model for multiple listeners of different applications is the Publish/Subscibe model.

If you code mulitple listeners that connect to a single receiver application, then this is not in conflict with the PTP model and can be considered.

The key aspect is not how many listeners are coded, but the number of applications that the sender wants to reach with the message.

One sender/one receiver via queues is Point-to-Point model.

One sender/multiple receivers via topics is Publish/Subscribe model.

[M Cassidy]

The original question was having multiple listeners on a queue. Not only is it possible, it is desirable to have multiple listeners for a queue. There is a difference between listener processes -- any of which can work on a request the same as the rest in parallel in separate threads or even on separate machines -- and having multiple different endpoint consumer processes which are pub/sub.

The whole point of Message Driven Beans used with Queues is to do that. For example, JBoss with an MDB/queue will start up as many MDB (listeners) as it deems necessary to handle the load, and you can have multiple EJB servers pointed to a shared persistent queue. Developers will recognize that doing lots of work in parallel possibly across multiple servers has a huge performance benefit compared with processing only one message at a time.