[
https://issues.apache.org/jira/browse/AMQ-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026707#comment-15026707
]
Christopher L. Shannon commented on AMQ-5898:
---------------------------------------------
If you don't run with assertions turned on, does your use case work?
It seems like the only fix here is to just drop the assertion line because I
can't really think of a good reason not to allow multiple composite
destinations to route to the same queue. In fact, I have done this several
times but never noticed this problem because I don't use assertions accept
during unit testing.
> Physical queues forwarded from many virtual destinations no longer supported
> ----------------------------------------------------------------------------
>
> Key: AMQ-5898
> URL: https://issues.apache.org/jira/browse/AMQ-5898
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.11.1
> Reporter: James Furness
> Attachments: ActiveManyCompositeQueuesToOnePhysicalQueueTest.java
>
>
> Hi Tim,
> AMQ-5187 breaks some of our message routing where we use virtual queues to
> control mirroring/replication of messages.
> A simple example...
> {code}
> VIRTUAL.PUB.ALL
> -> queue://SUBSCRIBER1
> -> queue://SUBSCRIBER2
> VIRTUAL.PUB.SUBSCRIBER1
> -> queue://SUBSCRIBER1
> {code}
> ...fails [this
> assert|https://github.com/apache/activemq/commit/f55edcfa25de1b55659a7113be60360c531ffa8a#diff-0def63df6ee6c0e4f8adcf00011b2f07R70]
> because there are two composite destinations that route to
> {{queue://SUBSCRIBER1}}. With asserts disabled messages are routed as
> expected.
> I have attached a test case exemplifying this.
> We use layers of composite queues to achieve explicit routing of messages to
> either one consumer or all consumers, and (also with static subscriptions) to
> target optimal routes across a mixture of LAN and WAN links.
> Fully appreciate that subscription recovery from virtual topics of a mapped
> queue is a beneficial thing to do, however from our perspective it is also
> useful to retain the behaviour of being able to have a many-to-one mapping
> between composite queues and physical queues. For our own use case we don't
> have any requirement for subscription recovery - we require cast-iron
> guarantees around messaging so all messages persistent and are delivered to
> one or more physical queues on brokers with persistence enabled, so this
> obviates the need for subscription recovery.
> Could this validation relaxed, could it be made possible for the new
> behaviour to be disabled or do you have any suggestions as to how else we
> could achieve our use case?
> Thanks,
> James
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
