[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

    [ 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)