You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (Updated) (JIRA)" <ji...@apache.org> on 2012/03/03 15:39:57 UTC
[jira] [Updated] (QPID-3548) qpid-route prevents linking between
exchanges on the same broker.
[ https://issues.apache.org/jira/browse/QPID-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell updated QPID-3548:
---------------------------------
Component/s: (was: Tools)
Python Tools
> qpid-route prevents linking between exchanges on the same broker.
> -----------------------------------------------------------------
>
> Key: QPID-3548
> URL: https://issues.apache.org/jira/browse/QPID-3548
> Project: Qpid
> Issue Type: New Feature
> Components: Python Tools
> Affects Versions: 0.10
> Environment: qpid-route
> Reporter: Fraser Adams
> Priority: Trivial
> Labels: features
>
> qpid-route has a test in the addLink method that explicitly prevents a user from creating a link between nodes on the same broker e.g.
> def addLink(self, remoteBroker, interbroker_mechanism=""):
> self.remote = BrokerURL(remoteBroker)
> if self.local.match(self.remote.host, self.remote.port):
> raise Exception("Linking broker to itself is not permitted")
> Raising an exception in this way seems excessive as it can often be useful to link nodes in this way.
> In my scenario I want to be able to send messages to a fanout exchange, have a processing consumer connect to one output queue and have a headers exchange linked to another queue off the fanout.
> After processing I want the processing consumer send its results to the headers exchange (so the headers exchange, and thus subscribers bound to it get both the unprocessed and processed data). Clearly I could stand up two broker instances and federate between them, however as far as I can see it's more efficient to link these things together on a single broker instance.
> There might be better ways to achieve this, and improvements to the broker's internal routing might arguably be a better approach, however equally there's probably an argument that federation is about linking AMQP nodes in a logical sense and that the broker forms part of a logical to physical mapping so it might make sense to employ the same approaches both inter and intra broker for linking nodes.
> If there are perceived issues linking a broker to itself then replacing the exception with a warning might be a fair compromise. I guess one issue might be circular links, however the irony is that the topology that I described above was put in place to solve a particular problem whilst avoiding a circular route.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org