[ https://issues.apache.org/jira/browse/AMQ-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026127#comment-15026127 ]
Lee Butts commented on AMQ-5898: -------------------------------- [~cshannon] this is a showstopper for us upgrading from 5.10 - could we get a fix for this into 5.13? > 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)