You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Fraser Adams (Created) (JIRA)" <ji...@apache.org> on 2011/10/14 11:58:11 UTC
[jira] [Created] (QPID-3548) qpid-route prevents linking between
exchanges on the same broker.
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: Tools
Affects Versions: 0.10
Environment: qpid-route
Reporter: Fraser Adams
Priority: Trivial
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
[jira] [Updated] (QPID-3548) qpid-route prevents linking between
exchanges on the same broker.
Posted by "Robbie Gemmell (Updated) (JIRA)" <ji...@apache.org>.
[ 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