[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068772#comment-16068772
]
Christopher L. Shannon commented on ARTEMIS-1262:
-------------------------------------------------
Actually, I think this can be solved by having the Core client keep track of
any durable non-shared subscriptions and comparing it against requests for
shared subscriptions. Since a non shared durable still requires a clientId
then it is guaranteed to have come from the same client. So this should be
able to be solved on the client side and not involve the broker. This seems to
be the strategy that qpid-jms uses:
https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpSubscriptionTracker.java
The reverse is also a violation (creating a non-shared durable with the same
clientId and name as a shared durable). The broker partially handles it
because if a durable subscription is online then the broker will reject future
non-shared durable creation attempts but if the subscription is offline then it
will be allowed as the check is done based off of the consumer count only.
> 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 the 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)
