CODEWITHSUNDEEP
javajmsmessage-queuepublish-subscribejms-topic
Sandeep Jindal
Sandeep Jindal

Reputation: 15368

JMS Topic vs Queue - Intent

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?

Upvotes: 6

Views: 6841

Answers (3)

jarnbjo
jarnbjo

Reputation: 34323

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".

Upvotes: 0

raffian
raffian

Reputation: 32086

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.

Upvotes: 6

John Ament
John Ament

Reputation: 11733

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.

Upvotes: 0

Related Questions