[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068777#comment-16068777
]
Christopher L. Shannon commented on ARTEMIS-1262:
-------------------------------------------------
[~clebertsuconic] - What do you think about this? I think this should be fixed
on the broker side. I thought it could be handled by the client but after
looking at the solution for the client side that qpid-jms did in more detail I
see two main issues:
1) The biggest flaw is the detection will still break for the offline durable
case. The client solution can only prevent the durable creation if it knows
about the existing durables and if the client has been restarted and there are
offline durables then the tracking won't be there for the offline durables
unless they were to come back online on that client.
3) It's still client side validation and really the broker should be enforcing
the validation so any client can be used.
> 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)
