ActiveMQ "Classic" has virtual topic functionality. This means that consumers can be created dynamically. How is this feature managed by ActiveMQ Artemis?
1 Answers
The point of virtual topics in ActiveMQ "Classic" was to deal with a particular limitation of JMS topics - the fact that only one consumer can be connected to a subscription at a time. Thus virtual topics allowed applications to send to a JMS topic and consume from a JMS queue since queues don't limit the number of consumers like subscriptions do.
ActiveMQ Artemis solves this problem in two ways.
- It provides full implementation of JMS 2. The shared subscription functionality available in JMS 2 eliminates the need for virtual topics, and since this is a standard part of JMS 2 that means the same application code can be used with any broker which implements JMS 2. This solves one of the main disadvantages of virtual topics which is vendor lock-in.
- The fundamental address model of ActiveMQ Artemis and the way JMS maps onto that model means that a "JMS subscription" is always represented as a core queue and any client (whether is uses JMS 2 or not) can use the fully qualified queue name to access that queue.
ActiveMQ Artemis also has special support for legacy ActiveMQ "Classic" clients which use virtual topic syntax.
Related