[
https://issues.apache.org/jira/browse/ARTEMIS-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16040347#comment-16040347
]
Michael Andre Pearce edited comment on ARTEMIS-1210 at 6/7/17 7:11 AM:
-----------------------------------------------------------------------
as per
http://download.oracle.com/otn-pub/jcp/jms-2_0-fr-eval-spec/JMS20.pdf?AuthParam=1496818906_544e2a077a653f0cb3812e9cb37c74fa
"
A durable subscription has a unique identity that is retained by JMS.
Subsequent consumer objects can resume the subscription in the state it was
left by the prior consumer. If there are no active consumers on a durable
subscription, JMS retains the subscription’s messages until they are consumed
or until they expire.
"
It seems that the onus to make the subscription globally unique. As such i
suspect that our incumbent jms broker technology that is supporting the ability
to support the subscription name used on different topics is not per spec but
over and above, as such I'm tempted to say this is a non-issue.
If anyone has any comments or feels that maybe artemis may want to support this
additional feature if not i will close/resolve this as won't fix.
was (Author: michael.andre.pearce):
as per
http://download.oracle.com/otn-pub/jcp/jms-2_0-fr-eval-spec/JMS20.pdf?AuthParam=1496818906_544e2a077a653f0cb3812e9cb37c74fa
"
A durable subscription has a unique identity that is retained by JMS.
Subsequent consumer objects can resume the subscription in the state it was
left by the prior consumer. If there are no active consumers on a durable
subscription, JMS retains the subscription’s messages until they are consumed
or until they expire."
It seems that the onus to make the subscription unique. As such i suspect that
our incumbent jms broker technology that is supporting the ability to support
the subscription name used on different topics is not per spec but over and
above, as such I'm tempted to say this is a non-issue.
If anyone has any comments or feels that maybe artemis may want to support this
additional feature if not i will close/resolve this as won't fix.
> Queue name should create Queue with Address in its name by default
> ------------------------------------------------------------------
>
> Key: ARTEMIS-1210
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1210
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Michael Andre Pearce
>
> When making a consumer for a topic (multicast) address, a queue is created
> named with for shared subscriber just the subscription name and if present
> client id only or in case of durable consumer it is the clientid + name only.
> This causes issue where client can validly use the same name's but for
> different address's.
> e.g.
> 2017-06-07 01:33:21.144 WARN 70432 --- [nerContainer-28]
> o.s.j.l.DefaultMessageListenerContainer : Setup of JMS message listener
> invoker failed for destination 'com.ig.trading.v0.order.history' - trying to
> recover. Cause: AMQ119082: Queue opstest already exists on another
> subscription
> To avoid this clash including the address in the queue name (as like for any
> cast queues) would solve this issue.
> Also it seems
> https://activemq.apache.org/artemis/docs/2.1.0/address-model.html alludes
> that actually this is the behaviour to include the address name in the
> consumer queue name.
> A clunky work around is obviously for the clients to ensure the name is
> globally unique by manually postfix'ing or prefix'ing the topic/address name.
> Though if this is the way forward the documents for address-model need to be
> updated with this detail, and avoid alluding to the pattern that the address
> is added by the system. Likewise frameworks like Spring would make a work
> around approach very fragile.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
