[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070175#comment-16070175
]
Robbie Gemmell commented on ARTEMIS-1262:
-----------------------------------------
Agreed on the bug report. Shared and non-shared durable subscriptions share a
single namespace when a ClientID is set, and non-shared durables arent possible
without one set.
All the things QpidJMS does client-side are just to satisfy various spec
conditions it can locally without the complication and inherent race-conditions
of contacting the broker to satisfy some of them. It also satisfies certain
conditions the AMQP protocol cant inherently without using extension points to
build a layered mechanism on top to do it. There are still conditions the
client can't detect itself and it relies on the broker to enforce them, with
reestablishing a subcriber to an inactive durable shared-vs-non-shared
subscription being one of those (see QPIDJMS-220 for more gory details)
Is the idea around changing queue names, that the client would name the
subscriptions differently and look for the other name? Thats a little racey,
but obviosuly better than not doing it.
If changing the queue names though, altering the default behaviour seems like a
major version / breaking change. Even if it is a bug it seems to be a long
standing one, so for anyone who hasnt hit it directly, the fix could still
break their existing subscriptions. I'd also link to ARTEMIS-1205 on related
discussion around that type of thing, i.e there are other changes that might be
made at similar time to better align subscription names across different
protocols.
> JMS 2.0 durable subscription spec violation
> -------------------------------------------
>
> Key: ARTEMIS-1262
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1262
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.1.0
> Reporter: Christopher L. Shannon
>
> There is a JMS 2.0 spec violation with Artemis. Currently it is possible to
> first create a durable subscription with a clientId and subscription name and
> then also create a shared durable subscription using the same clientId and
> subscription name. This works because Artemis isn't distinguishing between
> the two types of consumers during the creation of the consumer. However, the
> spec says:
> {quote}A shared durable subscription and an unshared durable subscription may
> not
> have the same name and client identifier. If the application calls one of the
> createSharedDurableConsumer methods, and an unshared durable
> subscription already exists with the same name and client identifier, then a
> JMSException or JMSRuntimeException is thrown.{quote}
> I think that there may need to be a flag added somewhere during the creation
> of the consumer so the broker can tell whether or not the durable
> subscription is shared vs non-shared so it can reject a shared subscription
> attempt if a non-shared subscription exists for the same client Id and name.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
