[
https://issues.apache.org/jira/browse/ARTEMIS-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036849#comment-16036849
]
Robbie Gemmell edited comment on ARTEMIS-1205 at 6/5/17 12:11 PM:
------------------------------------------------------------------
Tim's test code was aimed at your third point where the text indicates (and the
spreadsheet reiterates) issue during use of non-shared durable subscriptions
with different sub names but the same topic and ClientID. So the question is,
what is your non-shared test doing differently than Tim's working test?
(EDIT:..of course you edited that bit of your comment while I was replying :D)
For your attached test code, running
JMSSharedDurableConsumerTest#testSharedDurableConsumerSync I don't see anything
unexpected in the clients protocol trace. That suggests the issue is on the
broker side. To Tim's earlier description around your second point, based on
the spreadsheets mention of
“ID:bc269d2d-b24e-421f-9919-5ea1f7796218:1.foo:global” it looks like the broker
is including the clients container-id (and a 'global' discriminator) in the
name of the subscription backing queue created, which it shouldn't in this case
since doing so precludes the same backing queue ever being used for shared
subscribers on other connections which have different container-id values, and
would instead result in each connection getting their own backing queue
(similar to a non-shared subscription, but presumably still shared amongst
shared subscribers on that same connection). The intent of the 'global' flag on
the subscription link source (and their link names) is for connections with
differing container-ids (in this case, those without a JMS ClientID set) to all
share the same backing queues for a given subscription name.
was (Author: gemmellr):
Tim's test code was aimed at your third point where the text indicates (and the
spreadsheet reiterates) issue during use of non-shared durable subscriptions
with different sub names but the same topic and ClientID. So the question is,
what is your non-shared test doing differently than Tim's working test?
(EDIT:..of course you edited that bit of your comment while I was replying :D)
For your attached test code, running
JMSSharedDurableConsumerTest#testSharedDurableConsumerSync I don't see anything
unexpected in the clients protocol trace. That suggests the issue is on the
broker side. To Tim's earlier description around your second point, based on
the spreadsheets mention of
“ID:bc269d2d-b24e-421f-9919-5ea1f7796218:1.foo:global” it looks like the broker
is including the clients container-id (and a 'global' discriminator) in the
name of the subscription backing queue created, which it shouldn't in this case
since doing so precludes the same backing queue ever being used for shared
subscribers on other connections which have different container-id values, and
isntead results in each getting their own simialr to a non-shared subscription.
The intent of the 'global' flag on the subscription link source (and their link
names) is for connections with differeing container-ids (in this case, those
without a JMS ClientID set) to all share the same backing queues for a given
subscription name.
> AMQP Shared Durable Subscriber incorrect behaviour.
> ---------------------------------------------------
>
> Key: ARTEMIS-1205
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1205
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Michael Andre Pearce
> Priority: Blocker
> Attachments: AMQPMissbehaviour.xlsx, 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)
