6

I am trying to understand the use case of using Queue.

My understanding: Queue means one-to-one. The only use case(if not rare, very few) would be: Message is intended for only one consume.

But even in those cases, I may want to use Topic (just to be future safe). The only extra caution would be to make subscriptions durable. Or, in special situations, I would use bridging / dispatcher mechanism.

Given above, I would always (or in most cases) want to publish to a topic. Subscriber can be either durable topic(s) or dispatched queue(s).

Please let me know what I am missing here or I am missing the original intent?

Sandeep Jindal
  • 14,510
  • 18
  • 83
  • 121

3 Answers3

6

The design requirements on when to use queues are simple if you think in terms of real-world examples:

  • Submit online order (exactly-once processing to avoid charging credit card twice)
  • Private peer-to-peer chat (exactly one receiver for each message)
  • Parallel task distribution (distribute tasks amongst many workers in a networked system)

...and examples for when to use topics...

  • News broadcast to multiple subscribers; notification service, stock ticker, etc.
  • Email client (unique durable subscriber; you still get emails when you're disconnected)

You said...

But even in those cases, I may want to use Topic (just to be future safe). The only extra case I would have to do is to make (each) subscription durable. Or, I special situations, I would use bridging / dispatcher mechanism.

You're over-engineering the design. It's true, you can achieve exactly-once processing using a topic and durable subscriber, but you'd be limited to a single durable subscriber; the moment you start another subscriber for that topic, you'll get duplicate processing for the same message, not to mention, a single durable subscriber is hardly a solution that scales; it would be a bottleneck in your system for sure. With a queue, you can deploy 1000 receivers on 100 nodes for the same queue, and you'd still get exactly-once processing for a single message.

You said...

Give above, I would always (or in most cases) want to publish to a topic. Subscriber can be either durable topic(s) or dispatched queue(s).

Using a dispatched queue with a topic subscriber is sort of redundant. You basically get asynchronous dispatching when using queues, so why not just use a queue?...no reason to put a topic in front of it.

raffian
  • 31,267
  • 26
  • 103
  • 174
0

You are probably missing that both queues and topics can have multiple subscribers. A queue will deliver the message to one of potentially many subscribers, while a topic will deliver the message to all subscribers.

If you in your case are sure that there is only one subscriber, then a queue subscriber and a durable topic subscriber will behave similarly. I would rather look at such a scenario as a "special case".

Abdullah Khan
  • 12,010
  • 6
  • 65
  • 78
jarnbjo
  • 33,923
  • 7
  • 70
  • 94
  • 1
    2. My point is: Even in the "special case" i would want to go for Topic, because in future, I may want to have more than one subscriber for the message. – Sandeep Jindal Jul 02 '13 at 15:45
  • 1: Please clarify your question. Do you not understand what it means to have multiple subscribers (receivers in JMS language) to a queue? Due to the PTP semantics and that JMS guarantees that acknowledged messages are not redelivered, you can assume that a queue message is only delivered to one receiver. JMS does not specify to which receiver the message is delivered. 2: Noone but you can know if a queue or topic is suitable to satisfy your business requirements. – jarnbjo Jul 02 '13 at 16:10
  • Ok. I am trying to re-frame my question: What is a compelling reason to use a queue? Whatever can be achieved by queue can be achieved by Topic (along with more flexibility) with little extra caution of making subscribers durable. – Sandeep Jindal Jul 02 '13 at 16:46
  • A queue guarantees that a message is delivered to only one receiver. Using a topic, a message will be delivered to all receivers. I wrote that already in my original answer. – jarnbjo Jul 02 '13 at 17:03
  • Ok, I got it. My question: A queue "guarantee" that a message is delivered to "only one receiver". If we replace the queue with topic, we will get "Guarantee" using durable and "only one" using only one subscriber. With Topic, we will get additional benefits (that in future the message can be used by many. So, why not always publish to Topic? – Sandeep Jindal Jul 02 '13 at 17:15
  • 1
    Sometimes, the message sender does not care who processes the message put on the queue, but the message represents ONE task. There may be many competing queue consumers, effectively "multi-threading" the task execution. But you only want each task executed ONCE, so I know when I put a message on the queue, at some point, a consumer will pick it up and execute it. I don't get that with topics, because every subscriber will get a copy of my message. – Nicholas Jul 02 '13 at 17:28
  • @Nicholas Exactly for the problem you mentioned is JMS2 introduced "Shared Subscription" Concept. – Sandeep Jindal Jul 04 '13 at 15:27
  • I think you're missing the point. A common pattern for queues is for processing fire-and-forget asynchronous events, e.g say a clearing a credit-card transaction. Multiple threads can dispatch requests to the queue and forget about them. At the same time, multiple processors can listen on the queue, receive a task and execute it. No other task executor will get that task. If the queue is persistent, the tasks will be retained in the JMS "server" until they are expired or they're processed. JMS 2 Shared Subscriptions allow multiple consumers for one topic subscription. It's not the same thing. – Nicholas Jul 04 '13 at 20:07
0

Queues and Topics in JMS represent two different models - point to point and publish/subscribe. Topics will keep a message until all clients receive them, all subscribers handling them. Queues will wait for the first consumer to pull the message, and consider it read at that point.

John Ament
  • 11,595
  • 1
  • 36
  • 45