qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jjw tectec <jjw.tec...@gmail.com>
Subject Re: broker federation - qpid broker and Azure service bus
Date Mon, 24 Aug 2015 16:11:37 GMT
Hi Alan,

Thank you very much for your suggestion!

At first glance, I thought qpid dispatch might be my solution. However,
looking further, I found the documentation say "With a dispatch network,
all the receivers are connected to all the brokers. If there is a message
anywhere it can be delivered to any receiver." - which I think may not be
an appropriate solution for my situation.

The reason I'm thinking of using a local qpid broker between message
publishers and Azure Service Bus is to be able to use my local qpid broker
to store messages (in case there is disconnection of network between
clients and Azure cloud). I was hoping to set up persistent connection
between the local qpid broker and Azure Service Bus. In the proposed
scenario, messages will be sent from publishers to local qpid broker first,
and then forwarded to Service Bus. In the event of network connection, qpid
broker will be expected to store messages until connection with Azure cloud
is re-established, and forward accumulated messages...

Maybe qpid dispatch could be a solution; my 30-min quick glance of the
documentation did not give me correct understanding of the dispatch
feature. I'm reading / testing more to better understand it. Please let me
know if you got other thoughts. :)

Thanks again.

jjw



On Mon, Aug 24, 2015 at 10:27 AM, aconway <aconway@redhat.com> wrote:

> 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.
>
> Cheers,
> Alan.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message