qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aconway <acon...@redhat.com>
Subject Re: broker federation - qpid broker and Azure service bus
Date Mon, 24 Aug 2015 15:27:49 GMT
On Mon, 2015-08-24 at 09:58 -0500, jjw tectec wrote:
> We have the need to set up broker federation between qpid broker and 
> Azure
> Service Bus. I'm aware of the following discussion thread, and had 
> tried
> similar steps:
> https://mail-archives.apache.org/mod_mbox/qpid-users/201403.mbox/%3C5
> 317022A.2090108@redhat.com%3E
> However, to my disappointment, the suggested commands and many other
> command options I had tried didn't work, and I couldn't find any
> documentation that talks about setting up federation of heterogeneous 
> types
> of brokers.
> Is it really possible to set up federation between qpid and Azure 
> Service
> Bus using the "qpid-config" command? Or would I need to change source 
> code
> of qpid broker to make this work?
> I'm using qpid cpp 0.34 and qpid tools 0.32 by the way, and I had no
> problem of using "qpid-config" to set up broker federation consisting 
> of
> multiple qpid brokers.
> Hope to get your insight. Thanks very much,

This is not answering the question you are asking but it might be of
interest. You can use qpid dispatch, which is a "brokerless" AMQP
router to connect together brokers that don't know anything about each
other from the outside, rather than relying on the brokers to provide
the functionality you need. I have no idea if it fits your problem, but
it might.

There is a system test dispatch/tests/system_tests_broker.py which sets
up a "distributed queue" using multiple brokers. In the test they are
all qpidd, but they could be any AMQP-speaking broker. The idea is to
spread load. Dispatch provides a single "address" which the clients can
publish or subscribe to like a queue. However dispatch actually
distributes messages from publishers round-robin over all the brokers,
and routes messages from any broker that has them to any client that
wants them. The brokers don't know anything about it other than
providing a normal queue. Dispatch only routes messages, it does not
take any responsibility for them (other than to forwards the brokers
acknowledgement to the client), so features like persistence, HA etc.
in the brokers can work as normal.

There isn't a good writeup on this and there is a lot more work I want
to do on it, but it does work and is been used in at least one real
-world system under development. If it's interesting for your use case
I'd like to know about it.


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message