Hi Ted,
Somewhat ironically avoiding cyclic paths is *exactly* the reason I'm
interested in doing this.....
A couple of scenarios I'd like to implement are
1) I've got a number of consumers that take a mixture of processed and
unprocessed data and a processor that takes all the data going to the
other consumers, makes a type decision and processes data of a
particular type. I then want the processed data to go back to the other
consumers.
How I was hoping to achieve that was with a fan-out exchange that
delivers data to a headers exchange (where most of my consumers are
subscribing) and also to my processor. The idea then would be for the
processor to deliver its results to the headers exchange. With a single
exchange I can't see how I'd avoid looping back and forth to my
processor. BTW I realise that a better way to achieve this scenario is
to implement a request/response pattern between my consumers and my
processor/service but that involves business change that I'm still
working to get the people responsible for those components to buy into.
2) My second scenario relates to resilience. I had an idea that to
implement a higher level of resilience I could have two destination
brokers linked to a queue route on my source broker so I can effectively
"load balance" the output of my source across two brokers and if one of
these fails then the other would pick up all the data (assuming it had
the headroom). That's not a bad model, but it means around half the data
goes to one broker and half to the other.
I then had the thought (kind of based on scenario 1) where I could link
my source brokers to a fan-out exchange on each of the destinations and
each of these could fan-out to a headers exchange in its own broker and
a headers exchange on the alternate broker. In that way a consumer of
the headers exchange on either broker would end up receiving all of its data
I can obviously achieve scenarios 1 & 2 by having two brokers on each
server, but to be honest that seems to be a really inefficient way to
achieve what seems to be an entirely reasonable usage pattern.
Is there any good reason at all for preventing what (logically at least)
amounts to setting up an exchange route within a single broker. Is it
the broker or qpid-route that prevents this?
Re "For example, one could implement a binding that uses an exchange,
rather than a queue, as a destination" hmmm possibly. To my mind it
would seem that one of the most flexible ways to do this would be to
provide a QMF "connect" method on the exchange object that takes an
address string as an argument thus allow exchanges to connect to any
address. The problem I've got with the idea of using an exchange in a
binding is whether another temporary queue gets introduced between the
exchanges much like exchange routes. The worry I have with that type of
queue is that it gets created with default options (e.g. default size,
reject policy etc.) this is one of the reasons I tend to go with queue
routes as at least I have control of the queue specification - logically
I might prefer exchange routes but I'd like more control of the
temporary queue that gets established.
I want the earth don't I :-)
I'd love to know some opinions on how to achieve my scenarios above.
Frase
Ted Ross wrote:
Frase,
Federation can not be used to link two exchanges on the same broker as
it will not allow a broker to make a connection to itself.
I've heard requests for similar features that might be interesting for
us to consider. For example, one could implement a binding that uses
an exchange, rather than a queue, as a destination. In this case, a
message that matches the key in the binding would then be forwarded to
another exchange for a second round of routing. I'm sure there are
issues with this (i.e. cyclic paths) but it seems fairly straight
forward.
-Ted
On 09/09/2011 08:44 AM, fadams wrote:
Hello all,
We've done some federation where we've connected exchanges on different
brokers and experimented with exchange routes and queue routes but I'm
interested to know if it's possible to link different exchanges on
the same
broker.
I'm guessing it is possible, but what's the best way? Is it just a
case of
using qpid-route or is there another way of doing this?
Cheers,
Frase
--
View this message in context:
http://apache-qpid-users.2158936.n2.nabble.com/Connecting-exchanges-on-the-same-broker-tp6775844p6775844.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
