2
votes

It appears that durable topics in ActiveMQ (and this seems to be an impediment in JMS itself) that only one consumer can be active on a subscriber.

That is, in the ActiveMQ docs:

A JMS durable subscriber MessageConsumer is created with a unique JMS clientID and durable subscriber name. To be JMS compliant only one JMS connection can be active at any point in time for one JMS clientID, and only one consumer can be active for a clientID and subscriber name. i.e., only one thread can be actively consuming from a given logical topic subscriber.

Other queueing systems, however (looks like Azure Service Bus does this, based on the documentation), seem to easily allow multiple threaded "subscribers" on a single "subscription". In this day and age, one would think that would be a given.

Why is this the case? Is this going to be resolved in future versions of JMS and/or ActiveMQ?

P.S. It seems like "Virtual Topics" (the doc that's quoted above) is a not so ideal and not-so-performant workaround for this scenario, as it appears to create a completely separate queue in the background for each subscriber.

1

1 Answers

5
votes

Why is this the case?

The documentation you quoted states why this is the case - to be JMS compliant. To be clear, the JMS compliance here is with version 1.1. JMS 2.0 introduced "shared" durable subscribers

Is this going to be resolved in future versions of JMS and/or ActiveMQ?

ActiveMQ 5.x only implements JMS 1.1, and there are no plans I'm aware of to add support for JMS 2.0. However, ActiveMQ Artemis (another broker under the ActiveMQ banner that was built on top of a more modern, higher performance core) does support JMS 2.0 (among other protocols).

For what it's worth, there't not necessarily a performance problem with implementing a subscription in the broker with a queue. This is what ActiveMQ Artemis does and it has very good performance.