qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: Introducing Qpid Dispatch Router
Date Wed, 25 Sep 2013 15:18:34 GMT
This sounds like a good use case for Dispatch Router.  Please let me 
know if there is any way I can be of help to you.


On 09/25/2013 10:18 AM, Mitsuru Oka wrote:
> I am considering use of Dispatch Router for asynchronous task queue like
> Celery framework. But Celery is based on a broker such as RabbitMQ. I just
> dont want to use such the heavy broker,  because the task is no need to be
> durable. So, the Dispatch Router is relative good choice for me.
> If two or more tasks are there, I would use multiple topics for the tasks.
> Currently, I have no plan touse the group of consumers.
> Thanks,
> Mitsuru Oka
>   2013/09/25 22:14 "Ted Ross" <tross@redhat.com>:
>> Load-balanced fan-out is not currently implemented but is something that I
>> consider a key feature.  I'd be interested to hear if you have specific
>> requirements for how it works.
>> One interesting request I've heard is to be able to establish groups of
>> consumers for a "topic".  A message will be delivered to one consumer
>> within each group.  In other words, messages are broadcast to all groups
>> but are load-balanced within each group.
>> -Ted
>> On 09/25/2013 03:48 AM, Mitsuru Oka wrote:
>>> Hello, I'm new to Proton and Dispatch router.
>>> I'd like to know if the Dispatch Router support more complex patterns
>>> such as pub-sub. Especially, whether load balanced routing to
>>> subscribe node is implemented or not is my interesting point.
>>> Thanks,
>>> Mitsuru Oka
>>> 2013/9/17 Ted Ross <tross@redhat.com>:
>>>> I've been working on a sub-project within Apache Qpid called Qpid
>>>> Dispatch
>>>> Router.  I'd like to invite use, participation, feedback, criticism, etc.
>>>> There are a couple of basic introductory points to be made:
>>>>    * Dispatch Router is built on top of the Qpid Proton engine and driver
>>>>      APIs (The C implementations thereof).
>>>>    * A router is not a broker.  The idea of a message router was born
>>>>      from the awkwardness of trying to build scaled-up messaging networks
>>>>      out of brokers.
>>>>    * A network built from routers provides interconnect between brokers,
>>>>      between clients and brokers, or between clients and clients (i.e.
>>>>      point-to-point non-brokered).
>>>>    * The message router brings together the two separate worlds of
>>>>      Messaging and Networking.  Such a confluence was made possible by
>>>>      the AMQP 1.0 protocol.  The vision is to provide a messaging
>>>>      interconnect that has all the advanced semantics of AMQP along with
>>>>      the scale, resiliency, and ease of deployment of an IP network.
>>>> The code is in early stages of development and has not been through any
>>>> kind
>>>> of release.  It builds only in Posix-based environments (Linux, etc.)
>>>> and it
>>>> only functions as a single stand-alone router at present (inter-router
>>>> links
>>>> are not yet fully implemented).  The router can be used with both the
>>>> Proton
>>>> Messenger API and the Qpid Messaging Client APIs that support AMQP 1.0
>>>> (and,
>>>> in theory, with any AMQP 1.0 endpoint).
>>>> The code can be found in the Subversion tree under
>>>> "qpid/extras/dispatch".
>>>> http://svn.apache.org/repos/**asf/qpid/trunk/qpid/extras/**dispatch<http://svn.apache.org/repos/asf/qpid/trunk/qpid/extras/dispatch>
>>>> There is a draft web page for it here:
>>>>       http://qpid.apache.org/**components/dispatch-router/**index.html<http://qpid.apache.org/components/dispatch-router/index.html>
>>>> Qpid Dispatch Router will provide two basic mechanisms for message
>>>> routing.
>>>> *Message Routing* forwards individual messages to their destination(s)
>>>> based
>>>> on the address in the message's "to" field. *Link Routing* propagates
>>>> link-attaches across the network to the peer addressed in the link's
>>>> "source" or "target" field.  This is similar to creating a "virtual
>>>> channel"
>>>> across the network and allows the full semantics (transactions,
>>>> flow-control, etc.) to be provided end-to-end (as though the
>>>> participating
>>>> endpoints were directly connected).  Currently, only Message Routing is
>>>> implemented.
>>>> The following is a brief example of the router's use to illustrate how it
>>>> works:
>>>> [Refer to the README file for building instructions]
>>>> [The router executable and Proton Messenger examples are assumed to be in
>>>> the execution path]
>>>> Run the following in separate terminal windows:
>>>> $ router/dispatch-router -c <path-to-config-file>
>>>> $ recv amqp://**address/1<>
>>>> $ recv amqp://**address/1<>
>>>> $ recv amqp://**address/another<>
>>>> $ send -a amqp://**address/1<>CONTENT
>>>> $ send -a amqp://**address/another<>CONTENT
>>>> The first line starts the router process (assumed to be configured to
>>>> listen
>>>> on port 5672).  The "recv" examples create connections to the router and
>>>> subscribe to two different address (two use the same address).  The
>>>> "send"
>>>> examples create connections to the router and send messages to their
>>>> respective addresses.
>>>> If everything works, the first sent message will be received by the first
>>>> two receivers and the second sent message will be received only by the
>>>> third
>>>> receiver.
>>>> Regards,
>>>> -Ted
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<users-unsubscribe@qpid.apache.org>
>> For additional commands, e-mail: users-help@qpid.apache.org

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

View raw message