Github user mattrpav commented on the issue:
https://github.com/apache/activemq-artemis/pull/1820
@michaelandrepearce the IBM MQ scenario I was referring to was the ability
to use a named queue to back a topic subscription, not cloned subscriptions--
this provides the separation of producers from consumers in terms of "its a
different destination". This enables better wild card management for
permissions and other access features to destinations. ie.. topic://ORDERING.**
and queue://BILLING.**
I agree JMS 2.0 topic subscriptions solve the "same broker" and "same
destination" use case for application-side ability to dynamically add
additional consumers to a message flow without broker config or existing
producer and consumer(s) impacts.
Note: on the exclusive consumer part, it sounds like Artemis has a gap vs
5.x in that the exclusive consumer config is server-side only (separate issues
raised as [ARTEMIS-853] and [ARTEMIS-856]).
The key feature in the broker-to-broker message scenarios is that the
publishing destination is different than the consuming destination(s). In
ActiveMQ 5.x, this allows for two important multi-broker messaging patterns, as
well as enable the network of broker destination filtering (include / exclude),
client permissions and destination policy mapping via wild card syntax sugar
for administrators. See attached graphics
Multi-broker Use Case 1:
Multi-broker Use Case 2:
---
