Github user gemmellr commented on the issue:
https://github.com/apache/activemq-artemis/pull/1316
Given that all the queues exist in the same ultimate namespace, there will
obviously always be potential for collisions unless 'regular queues' had some
name mangling applied too (which is undesirable, and was removedin 2.x because
of it). I don't dispute this, I just think it is a question of severity and
whether one subscription type by default will/could easily collide with another
as well as entirely unrelated things such as regular queues with simple names.
Someone with a queue called "foo", and a topic called "bar" and a client
who makes a no-ClientID subscription named "foo", should be allowed to. With
the existing format (minus the container-id bug) they would be able to on the
AMQP side. With the aligned one they will not as the queue and subscription
names would be directly used the same way without attempt to avoid collision in
use of these essentially unrelated values.
The addition of a ":global" suffix was not incorrect, the implementation
simply had a related bug in it. The quoted JMS spec excerpt (I assume is from
createSharedDurableConsumer, not the linked unsubscribe) and example are not
actually applicable to it, as the ":global" suffix only applies for shared
subscriptions on connections without a ClientID, which cant have non-shared
durable subscriptions (i.e they need a ClientID to be set). The ":global"
suffix exists precisely to separate those 'global sub backing' queue names from
being named directly the same way as regular queues and other sub types when
presented with simple name "foo". If you go to the effort of naming all your
regular queues "foo:global" etc then I agree you can still cause the same
collisions, but I think at that point its actually reasonble to say there is a
naming convention and you need to take it into account, as its far less likely
to be hit and the default for every simple name "foo" was not for them to c
ollide.
The ":shared-volatile" and ":global" suffixes also help prevent a durable
[shared] subscription backing queue name from easily colliding with a
non-durable one, or with those from connections with ClientID's. Removing those
with the alignment, that then becomes somewhat more likely, unless the "."
escaping is done, which as discussed could break existing subscriptions.
Obviously, use of regular queues could again be made to collide names with any
naming convention used here, but again for me the key bit is typically only
with some deliberate effort.
The issue noted with unsubscribe (which I was planning to test+fix after
this JIRA was complete) will most likely be that the broker is not looking in
the correct place for the "global" flag as it applies during unsubscribe. This
is unfortunately in a different place than it is the rest of the time due to
how the complicated AMQP<->JMS mapping must work for shared subs. Typically the
flag is added as an AMQP 'source capability', but during unsubscribe the is no
'source' information present so instead it gets passed as a 'link desired
capability'. The change to add the below would actually work for the JMS
client, but would typically fail/be-incorrect for any non-JMS clients using the
mechanism. Whats needed is inspecting the link capabilities and passing the
correct global value into the naming method.
```
+ if (pubId.endsWith("|global")) {
+ global = true;
+ }
```
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
