231

I was wondering what is the difference between a JMS Queue and JMS Topic.

ActiveMQ page says

Topics

In JMS a Topic implements publish and subscribe semantics. When you publish a message it goes to all the subscribers who are interested - so zero to many subscribers will receive a copy of the message. Only subscribers who had an active subscription at the time the broker receives the message will get a copy of the message.

Queues

A JMS Queue implements load balancer semantics. A single message will be received by exactly one consumer. If there are no consumers available at the time the message is sent it will be kept until a consumer is available that can process the message. If a consumer receives a message and does not acknowledge it before closing then the message will be redelivered to another consumer. A queue can have many consumers with messages load balanced across the available consumers.

I want to have 'something' what will send a copy of the message to each subscriber in the same sequence as that in which the message was received by the ActiveMQ broker.

Any thoughts?

U13-Forward
  • 69,221
  • 14
  • 89
  • 114
Poliquin
  • 2,937
  • 4
  • 28
  • 32

10 Answers10

174

That means a topic is appropriate. A queue means a message goes to one and only one possible subscriber. A topic goes to each and every subscriber.

Joseph Ottinger
  • 4,911
  • 1
  • 22
  • 23
  • 5
    Any idea how does the load balancing work for the Queues in JMS or WSO2 MB ? – Kulasangar Apr 18 '16 at 16:36
  • that's interesting because I was trying to debug some subscriber and when sending a topic the subscriber was not called but when sending to the queue it worked – vmrvictor Jul 23 '19 at 10:25
  • To be more accurate, for example with RabbitMQ you can use a fanout exchange mechanism that will send the same message to all assigned queues, so many consumers will receive it. Not exactly the pub-sub, but can do a similar thing. – user07 Oct 20 '21 at 15:14
70

It is simple as that:

Queues = Insert > Withdraw (send to single subscriber) 1:1

Topics = Insert > Broadcast (send to all subscribers) 1:n

enter image description here

Daniel Perník
  • 5,464
  • 2
  • 38
  • 46
  • 9
    An example can be for a simple social network. Someone ‘likes’ a post. The backend publishes a ‘POST LIKE’ event to the topic. It’s consumed by 3 subscribers: ```notificationProcessor``` (sends a notification to the poster), ```karmaProcessor``` (gives karma to liker and poster), ```feedProcessor``` (moves jot upwards into people’s feeds). All asynchronously of course. – Siddhartha Sep 23 '19 at 04:27
  • @Siddhartha, this could be an answer wrapped-in an example, thanks ! – SeleM Feb 20 '20 at 16:36
62

Topics are for the publisher-subscriber model, while queues are for point-to-point.

David Newcomb
  • 10,639
  • 3
  • 49
  • 62
vikram
  • 629
  • 5
  • 2
45

A JMS topic is the type of destination in a 1-to-many model of distribution. The same published message is received by all consuming subscribers. You can also call this the 'broadcast' model. You can think of a topic as the equivalent of a Subject in an Observer design pattern for distributed computing. Some JMS providers efficiently choose to implement this as UDP instead of TCP. For topic's the message delivery is 'fire-and-forget' - if no one listens, the message just disappears. If that's not what you want, you can use 'durable subscriptions'.

A JMS queue is a 1-to-1 destination of messages. The message is received by only one of the consuming receivers (please note: consistently using subscribers for 'topic client's and receivers for queue client's avoids confusion). Messages sent to a queue are stored on disk or memory until someone picks it up or it expires. So queues (and durable subscriptions) need some active storage management, you need to think about slow consumers.

In most environments, I would argue, topics are the better choice because you can always add additional components without having to change the architecture. Added components could be monitoring, logging, analytics, etc. You never know at the beginning of the project what the requirements will be like in 1 year, 5 years, 10 years. Change is inevitable, embrace it :-)

Axel Podehl
  • 4,034
  • 29
  • 41
13

Queues

Pros

  • Simple messaging pattern with a transparent communication flow
  • Messages can be recovered by putting them back on the queue

Cons

  • Only one consumer can get the message
  • Implies a coupling between producer and consumer as it’s an one-to-one relation

Topics

Pros

  • Multiple consumers can get a message
  • Decoupling between producer and consumers (publish-and-subscribe pattern)

Cons

  • More complicated communication flow
  • A message cannot be recovered for a single listener
abhimanyu
  • 730
  • 1
  • 10
  • 23
8

As for the order preservation, see this ActiveMQ page. In short: order is preserved for single consumers, but with multiple consumers order of delivery is not guaranteed.

eebbesen
  • 5,070
  • 8
  • 48
  • 70
4

If you have N consumers then:

JMS Topics deliver messages to N of N JMS Queues deliver messages to 1 of N

You said you are "looking to have a 'thing' that will send a copy of the message to each subscriber in the same sequence as that in which the message was received by the ActiveMQ broker."

So you want to use a Topic in order that all N subscribers get a copy of the message.

Hans Jespersen
  • 61
  • 2
3

TOPIC:: topic is one to many communication... (multipoint or publish/subscribe) EX:-imagine a publisher publishes the movie in the youtub then all its subscribers will gets notification.... QUEVE::queve is one-to-one communication ... Ex:-When publish a request for recharge it will go to only one qreciever ... always remember if request goto all qreceivers then multiple recharge happened so while developing analyze which is fit for a application

siddartha kamble
  • 159
  • 1
  • 3
1

I prefer a deep explanation about Topics and Queues instead of a simple comparison, if you really want to learn the differences, then an extensive explanation will be good:

In default configuration, Consumers in the Queue and in the Topic "receive" the messages, they don't "get" the messages, they "listen" and the Broker "sends" the messages.
The Broker "pushes" messages to the consumers.
It's because pushing messages have a high throughput, and it's scalable.
This process is always asynchronous.

You can "get" messages in a Queue, but not in a Topic. When you "get" a message, this process is synchronous, and it isn't scalable.

enter image description here

In the Queue, with many consumers, only the first consumer receives the message.
Generally, the Queue delivery the messages using a Round Robin pattern. The Round Robin pattern is a way to distribute the messages equally, the broker sends the first message to consumer A, then sends the second message to consumer B, then sends to consumer C. After sending to all consumers, the broker sends the next message to consumer A again, and so on.

In the Topic all subscribers listening it will receive the messages.
If one of the subscribers in the Topic is offline and the others subscribers receive the message, the offline subscriber will lose that message. And If all subscribers are offline, the message will be lost.

enter image description here

In Topic if you configure a subscriber as durable then if it goes down, the broker waits the subscriber come back online:

Scenario where Non-Durable Subscriber offline lost messages enter image description here

Scenario where Durable Subscriber offline doesn't lose messages enter image description here

In other hand, if the consumer in the Queue is offline, the Broker will wait the consumer come back (Obviously if the queue isn't a competing consumers).

In summary, when the Broker receives a new message, it looks for one of the consumers listening the queue, get the reference of one of them, and send the message. When the Broker receives an acknowledgment (confirmation) from the consumer that the message was received with success, the Broker deletes Queue's message.

When is a Topic, The Broker consults all subscribers currently listening it, sends the message to everyone, and waits for their return (acknowledge), when all subscribers send an ok, it deletes the message.

Grouping Messages in a Queue

In a queue with competing consumers, or in a cluster of brokers, you can provide a way to identify a set of related messages.

Using group id you can guarantee the order in which messages are processed. e.g. you don’t want to process the update to an order until an insert has been done.

The messages could be related by anything - a customer order number, for example. Basically a JMS broker provides a guarantee that any messages that belong to a specific group will always be consumed by a common consumer.

danilo
  • 7,680
  • 7
  • 43
  • 46
-1

Queue is JMS managed object used for holding messages waiting for subscribers to consume. When all subscribers consumed the message , message will be removed from queue.

Topic is that all subscribers to a topic receive the same message when the message is published.

Geetha reddy Manukonda
  • 98
  • 2
  • 7
  • 2
    Queue messages will only be consumed _once_ by a _single_ consumer, that's why a queue implements a load balancer. Topic subscriptions can be [_durable_](http://activemq.apache.org/how-do-durable-queues-and-topics-work.html): the subscriber can receive the message long after publication (if the subscriber was shut down and comes up again, for instance). – Gruber Aug 17 '15 at 09:16