activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (AMQ-5898) Physical queues forwarded from many virtual destinations no longer supported
Date Wed, 25 Nov 2015 13:47:11 GMT


ASF subversion and git services commented on AMQ-5898:

Commit a38c3d4b6b9a4e828c80e88dd5a33c86fae99a06 in activemq's branch refs/heads/activemq-5.12.x
from [~cshannon]
[;h=a38c3d4 ]

Removing assertion in VirtualDestinationInterceptor to allow
multiple composite destinations to forward to a physical destination

(cherry picked from commit 35b7ac250b5fa0b8c8dbf728881cc9dbf6edce19)

> Physical queues forwarded from many virtual destinations no longer supported
> ----------------------------------------------------------------------------
>                 Key: AMQ-5898
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.11.1
>            Reporter: James Furness
>         Attachments:
> 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}
> -> queue://SUBSCRIBER1
> -> queue://SUBSCRIBER2
> -> queue://SUBSCRIBER1
> {code}
> ...fails [this assert|]
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

View raw message