[
https://issues.apache.org/jira/browse/ARTEMIS-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042734#comment-16042734
]
Robbie Gemmell edited comment on ARTEMIS-1205 at 6/8/17 2:07 PM:
-----------------------------------------------------------------
I've been looking at the effect of the naming changes made here and the
resultant new behaviour for \[JMS\] AMQP clients. The changes introduce various
issues that did not previously exist, and so I think its worth considering
whether it was actually the correct thing to do.
Some issues:
- Durable subscription backing queues for connections without a ClientID now
share the same namespace as regular queue names, and things fail (in an not
very helpful and/or somewhat incorrect fashion) when they do collide, when
reasonably they should succeed.
- Following from the above, durable subscription backing queues for
subscriptions on connections without a ClientID can collide with durable
subscription backing queue names for connections with ClientIDs. Its not clear
the broker would notice. \[EDIT: see note below on latest change\]
- Durable and non-durable subscription backing queue names can collide, either
within a connection with a ClientID, across connections without a ClientID, or
across those with ClientIDs and without ClientIDs. \[EDIT: see note below on
latest change the latest change\]
- Its unclear as yet if calling session#unsubscribe(subName) can delete the
'wrong thing' (i.e. a queue of the same name, rather than the subscription
backing queue) when theres no ClientID as unsubscribe doesnt seem to work when
the connection has no ClientID.
I think its likely that the adressing changes in Artemis 2.0 may have
contributed to some of the issues, as in 1.x the core 'JMS queue' and 'JMS
topic' names were prefixed on the broker, preventing some of the collisions
entirely and making others much more unlikely.
EDIT: the latest change may fix most/all the issues on the second and third
list items, since the dots needed in the sub names to foul the clientID or
'nonDurable' seperating elements in the queue name would then get escaped. Its
worth noting however that this change could itself come at the expense of
breaking existing subscriptions already doing that, which is basically itself
another issue being introduced.
was (Author: gemmellr):
I've been looking at the effect of the naming changes made here and the
resultant new behaviour for \[JMS\] AMQP clients. The changes introduce various
issues that did not previously exist, and so I think its worth considering
whether it was actually the correct thing to do.
Some issues:
- Durable subscription backing queues for connections without a ClientID now
share the same namespace as regular queue names, and things fail (in an not
very helpful and/or somewhat incorrect fashion) when they do collide, when
reasonably they should succeed.
- Following from the above, durable subscription backing queues for
subscriptions on connections without a ClientID can collide with durable
subscription backing queue names for connections with ClientIDs. Its not clear
the broker would notice.
- Durable and non-durable subscription backing queue names can collide, either
within a connection with a ClientID, across connections without a ClientID, or
across those with ClientIDs and without ClientIDs.
- Its unclear as yet if calling session#unsubscribe(subName) can delete the
'wrong thing' (i.e. a queue of the same name, rather than the subscription
backing queue) when theres no ClientID as unsubscribe doesnt seem to work when
the connection has no ClientID.
I think its likely that the adressing changes in Artemis 2.0 may have
contributed to some of the issues, as in 1.x the core 'JMS queue' and 'JMS
topic' names were prefixed on the broker, preventing some of the collisions
entirely and making others much more unlikely.
> AMQP Shared Durable Subscriber incorrect behaviour.
> ---------------------------------------------------
>
> Key: ARTEMIS-1205
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1205
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Michael Andre Pearce
> Assignee: Michael Andre Pearce
> Priority: Blocker
> Fix For: 2.2.0
>
> Attachments: AMQPMissbehaviour.xlsx, JMSDurableConsumerTest2.java,
> JMSSharedDurableConsumerTest.java
>
>
> Summary observations :
> • There’s different behaviour between AMQP and the Artemis clients
> • There's UUID subscription name in the subscription topic when you’re
> using the AMQP client, you don’t set the client ID and you’ve selected a
> durable & shared subscription. It should just be the subscription name, like
> with the Artemis client.
> • The AMQP client seems to have a problem if you try to create a new
> durable, non-shared subscription on the same topic with the same client ID
> and a different subscription name.
>
> The artemis client doesn’t have a problem with this.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
