activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gemmellr <...@git.apache.org>
Subject [GitHub] activemq-artemis issue #1316: ARTEMIS-1205: AMQP Shared Durable Subscriber i...
Date Fri, 09 Jun 2017 10:21:10 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message