[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070175#comment-16070175
]
Robbie Gemmell commented on ARTEMIS-1262:
-
Agreed on the bug report. Shared and non-shared durable subscriptions share a
single namespace when a ClientID is set, and non-shared durables arent possible
without one set.
All the things QpidJMS does client-side are just to satisfy various spec
conditions it can locally without the complication and inherent race-conditions
of contacting the broker to satisfy some of them. It also satisfies certain
conditions the AMQP protocol cant inherently without using extension points to
build a layered mechanism on top to do it. There are still conditions the
client can't detect itself and it relies on the broker to enforce them, with
reestablishing a subcriber to an inactive durable shared-vs-non-shared
subscription being one of those (see QPIDJMS-220 for more gory details)
Is the idea around changing queue names, that the client would name the
subscriptions differently and look for the other name? Thats a little racey,
but obviosuly better than not doing it.
If changing the queue names though, altering the default behaviour seems like a
major version / breaking change. Even if it is a bug it seems to be a long
standing one, so for anyone who hasnt hit it directly, the fix could still
break their existing subscriptions. I'd also link to ARTEMIS-1205 on related
discussion around that type of thing, i.e there are other changes that might be
made at similar time to better align subscription names across different
protocols.
> 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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069876#comment-16069876
]
Christopher L. Shannon commented on ARTEMIS-1262:
-
Alright, thanks for the feedback, I'll play around with it a bit and will
create a PR for it. I think you are right that the queue name is probably the
best way to go instead of a protocol change. So somewhere on the server the
check would have to be done to make sure the durables are following the spec
and return an error to the client if the queue creation is invalid. Under the
old model it would make sense to put this logic into the JMSServerManager but
that is deprecated. So will need to figure out where to put this without
enforcing it on other protocols that don't have this restriction.
> 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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068919#comment-16068919
]
clebert suconic commented on ARTEMIS-1262:
--
I don't think this will need a protocol change. The client has control over the
queue name. as the implementation will call createQueue for the subscription.
you will probably need a property on the connection factory somehow to use the
old queue name. Not sure if the default should be the proper implementation or
the wrong one. I vote to have the impl ellecting the new one
> 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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068896#comment-16068896
]
Timothy Bish commented on ARTEMIS-1262:
---
The specification is actually pretty clear here on how the types of Topic
subscriptions should behave. I'd encourage you to read section 8.3 a couple
times if it seems unclear. To say that a JMS client / broker should ignore the
specification seems a bit wrong-headed to me. You have a user whose reported
that this is an issue for them so I'd encourage you to investigate it and not
dismiss it offhand as Artemis is supposed to be a JMS messaging system.
> 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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068873#comment-16068873
]
clebert suconic commented on ARTEMIS-1262:
--
There's no way to comply with both statements.. separate subscription.. on
which case you keep it separate.. and throw an exception in case of a same
name...
The spec is confusing here.. I think we should ignore it... the risk of any
issues is low anyways...
If you really want to fix it.. we would need to change the name with a suffix
such as .durable.. shared... and some convoluted checks if the version is
applied or not.. that is.. the fix gets more dangerous than what we have in
place now.
> 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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068863#comment-16068863
]
Christopher L. Shannon commented on ARTEMIS-1262:
-
I think you may be misreading it or mixing up shared non-durable versus shared
durable. In this case, yes a shared non-durable consumer is separate from a
shared durable subscription and the subscriptions are different.
However in the case of non-shared durable subscriptions and shared durable
subscriptions there is a restriction. The javadoc you linked says:
"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."
So an exception needs to be thrown.
> 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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068828#comment-16068828
]
clebert suconic commented on ARTEMIS-1262:
--
[~cshannon] hmnmmm..
Looking at the javadoc:
https://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html#createSharedDurableConsumer-javax.jms.Topic-java.lang.String-
There is no restriction on durable subscriptions and shared non-durable
subscriptions having the same name and clientId. Such subscriptions would be
completely separate.
The issue is that this is sharing the same queue... it should be a separate
queue...
However.. fixing that may break compatibility. We would need to add a flag on
the connection factory :/
> 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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
[
https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068743#comment-16068743
]
Christopher L. Shannon commented on ARTEMIS-1262:
-
Here is a test I added to the existing JMS 2.0 tests that show the violation:
https://github.com/cshannon/activemq-artemis/commit/e78d7b7bf3bb7619b67aeac53b6e924087a64c0d
> 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)
