Hi all.
In case anyone is following this thread, it turns out that it's only
qpid-route (not the broker) that is preventing this from being possible
- and it's just a case of commenting out a couple of lines in qpid-route
to get it to work :-)
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")
brokers = self.agent.getObjects(_class="broker")
etc.....
etc.........
so as an experiment I commented out the test that checks if an attempt
has been make to link to self
I did qpid-config add queue test
Then attempted to create a queue route between the queue test and
amq.match on localhost
./qpid-route-patched queue add localhost localhost amq.match test
Everything seems happy with qpid-route route map localhost:
Finding Linked Brokers:
localhost:5672... Ok
Dynamic Routes:
none found
Static Routes:
localhost:5672(ex=amq.match) <= localhost:5672(queue=test)
So I ran a producer with an address of "test" and a consumer with its
own queue and a set of bindings to amq.match and I'm pleased to report
that my messages were happily delivered!!!!!!
So unless somebody can come up with a real good reason why it's a good
idea to have the test in qpid-route can I please as that it gets removed
in the next qpid release? Obviously I can use my patched version for
now, but wherever possible I'm keen to use qpid "out of the box".
As a slight aside am I correct in thinking that when federating using
exchange routes there's only the option of specifying a single exchange?
This seems pretty limiting. Obviously with dynamic routes the source and
destination exchanges need to be the same exchange *type* but surely
there's no reason that they need to have the same name. For static
exchange routes they don't even need to be the same type as you can
specify the routing-key that binds the source exchange to the temporary
queue that gets created.
Again I think this is actually an issue with qpid-route, which has a line:
link.bridge(config._durable, exchange, exchange, routingKey, tag,
excludes, False, config._srclocal, dynamic, config._ack)
however the spec for the bridge method on link says:
<method name="bridge" desc="Bridge messages over the link">
<arg name="durable" dir="I" type="bool"/>
<arg name="src" dir="I" type="sstr"/>
<arg name="dest" dir="I" type="sstr"/>
<arg name="key" dir="I" type="lstr"/>
<arg name="tag" dir="I" type="sstr"/>
<arg name="excludes" dir="I" type="sstr"/>
<arg name="srcIsQueue" dir="I" type="bool"/>
<arg name="srcIsLocal" dir="I" type="bool"/>
<arg name="dynamic" dir="I" type="bool"/>
<arg name="sync" dir="I" type="uint16"/>
</method>
So there's actually no particular limits on the src Node.
Are there any good reasons for having the tool limit the flexibility
that the underlying mechanism actually allows. Obviously developer types
can hack the tools or use their own QMF consoles, but non-developers
could be a little stuck if they want to introduce more sophisticated
topologies.
Hope that this info is useful and I'd appreciate the opinions of others
on this.
Regards,
Frase
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
