[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16433785#comment-16433785
]
Christopher L. Shannon commented on ARTEMIS-1262:
-------------------------------------------------
I started looking at this more again and about how we can do this. There are 2
separate issues here, the first is to make sure the shared and non shared
durables are separate subscriptions (now they end up as the same which is an
issue) and the second is to disallow the creation of both in the same namespace.
The first problem can be solved with changing the queue names and then
naturally the non-shared durable and shared durable subscriptions will be
separate. The nice thing about this is it can be done just in the JMS client
and not break other protocols and a flag can be used to configure the naming
scheme for the queue for backwards compatibility.
The second issue is more tricky in how to enforce the namespace issue. As
Robbie pointed out there will be race condition issues if we try and have the
client do the check. The other way would be to put the check on the broker side
(do a check when the binding/queue is created under a lock) but then we run
into the issue of enforcing this behavior across all protocols which we may or
may not want to do. It would also obviously be a breaking change and require a
major version upgrade.
At the very least I think the the queue name should be changed and do the check
on the client side even if it isn't perfect. To me it's a big problem if a
client creates a non-shared durable subscription and then another client later
creates a durable subscription with the same clientId/subname and then suddenly
the broker promotes the original non-shared durable subscription to a shared
and both clients share the same queue.
> 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
> Priority: Major
>
> 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
(v7.6.3#76005)
