activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "clebert suconic (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation
Date Thu, 29 Jun 2017 20:17:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Mime
View raw message