CODEWITHSUNDEEP
javajmsactivemq-classic
Wand Maker
Wand Maker

Reputation: 18762

ActiveMQ - Best practice for creating queues/destinations

In ActiveMQ, should we create separate queue (destination) for each different types of events so that we can have different consumers processing such events?

Or should we publish a generic event and then, inspect the event in consumer to figure out its type and take appropriate action.

For instance: If there are two events, UserCreatedEvent and UserActivatedEvent, should we have one queue user_events_q, or should we have two queues user_created_events_q and user_activated_events_q?

Is there any disadvantage in having more queues? Will it require more resources? What is the typical practice in this kind of scenario?

Upvotes: 0

Views: 2060

Answers (2)

Petter Nordlander
Petter Nordlander

Reputation: 22279

You probably want to limit the number of queues somewhat. Maybe keep it below 100 or so. If you use tools like Hawt.io or web console - a very high number of queues will not work very well. Although you can theoretically use a large amount of queues maybe with some tweaking.

The nice parts of separate queues are:

  • A dedicated Dead Letter Queue per Queue
  • Authorization is "per queue".
  • Policies can be applied on a queue level - i.e. max memory, DLQ strategy, etc.
  • Simpler client side code.

You can multiplex event types on a shared queue by using selectors. A certain client will only receive messages it needs by looking at some message property. I.e. EventType = 'StockUpdate'. This may be one way to reduce the number of queues.

The other way is to use topic hierarchies instead. It does not map to queues exactly but may be an option. Say you publish to different topics: StockUpdates.Nasdaq.AAPL or StockUpdates.DeutscheBorse.VOW3.

So if you want to subscribe to only Nasdaq, use StockUpdates.Nasdaq.> or if you want only Volkswagen stock updates, StockUpdates.DeutscheBorse.VOW3.

Upvotes: 1

Akhil
Akhil

Reputation: 1274

Definitely having multiple queues will use extra resources like when the object is put into queue then it remains in memory (if persistent queue is not used) and also broker needs to maintain some metadata for each queue, but this is the overhead one can live with because having a dedicated queue for each event (in your case) provides great flexibility and scalibility. For an instance a new event is introduced then you can simply introduce a new consumer to read from that queue, leaving aside the existing implementation.

Upvotes: 1

Related Questions