[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068901#comment-16068901
]
Christopher L. Shannon commented on ARTEMIS-1262:
-------------------------------------------------
Again, I think you are misreading it. The spec is clear and you can comply
with both statements. One statement refers to shared durable and unshared
durable. The second statement refers to durable subscriptions (either unshared
or shared) and normal topic message consumers (non-durable) subscriptions.
{quote}A *shared durable* subscription and an *unshared durable* subscription
may not have the same name and client identifier (if set). If an unshared
durable subscription already exists with the same name and client identifier
(if set) then a JMSRuntimeException is thrown.
There is no restriction on *durable* subscriptions and shared *non-durable*
subscriptions having the same name and clientId (which may be unset). Such
subscriptions would be completely separate.{quote}
So in the case I am talking about an exception should be thrown.
In my opinion I do not think it should be ignored. While it may be low risk in
my opinion if a broker advertises itself as a JMS 2.0 broker then it needs to
implement the entire spec correctly. (The same for any other protocol or spec)
I am happy to work on a PR for this but figure it would be best to discuss it
first. The main reason I'm starting a discussion is because it will be tricky
to fix and to be compatible as you alluded to. It will probably require a
protocol change and some other piece of information to be sent during the
subscription creation, etc.
> 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)
