activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ARTEMIS-1205) AMQP Shared Durable Subscriber incorrect behaviour.
Date Mon, 05 Jun 2017 12:07:04 GMT

    [ 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:06 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 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.


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?

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)

Mime
View raw message