qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Connecting exchanges on the same broker
Date Sat, 10 Sep 2011 05:45:54 GMT

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:users-subscribe@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message