Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
To track our offline conversations.
For sake of conversation I'm describing the equivilent "virtual topics"
feature as a "shared subscription".
We've established the use case for the linked JIRA: ARTEMIS-592 which is to
do with securing "shared subscriptions" queues (Or what ever we want to call
this functionality). Justin has added the ability to secure individual queues
in this PR. This can be used to secure a shared subscription queue and also
secure any other queue. At this moment in time, we can't explicitly define a
shared subscription queue (as ActiveMQ do with virtual topics). But it may be
possible to do something similar by connecting 2 clients with the same client
ID to the broker (due to the way we internally create unique queueNames based
on ClientID+SubscriptionName). I'm not even sure if this is possible it needs
testing. I know with other protocols, for example MQTT, only a single client
with the same ID can be connected at a time and allowing 2 clients to connect
at the same time may not be a trivial change.
My comments above are an attempt to make this feature configurable in a
more user friendly way. Right now, with this solution the user is required to
understand and construct the queueName and explicitly define it for every
shared subscription.
The above solution I outlined allows admins to group users together and
allow them to share subscriptions between themselves, on any address that
matches the security-setting filter. With out needing to deal with explicit
queues, This is less explicit and more easily configurable imo. It does
however, introduce the concept of a subscription to Artemis configuration which
seems to be a sticking point for both @jbertram and @clebertsuconic as it's not
part of the Artemis Core. (This could be configured in a non-core part of the
broker config).
However, there is another use case for this patch, to do with securing
queues on the core protocol. So perhaps we merge it for that reason, with the
added benefit that it adds the ability to secure a subscription queue.
@clebertsuconic and @jbertram I think I'm out numbered here, so I'll let
you guys go ahead and do what you feel is best.
Thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
