[
https://issues.apache.org/jira/browse/AMQ-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15027419#comment-15027419
]
ASF subversion and git services commented on AMQ-5898:
------------------------------------------------------
Commit 95f58fa7c4e26b5b2d73a80bd8e1cb2bee8ebf47 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=95f58fa ]
https://issues.apache.org/jira/browse/AMQ-6027
Adding back in test case now that AMQ-5898 is resolved
> 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
> Assignee: Christopher L. Shannon
> Fix For: 5.13.0, 5.12.2
>
> 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)
