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" <tr...@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 <tr...@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://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1> >>> $ recv amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1> >>> $ recv >>> amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_address/another> >>> $ send -a >>> amqp://0.0.0.0:5672/my_**address/1<http://0.0.0.0:5672/my_address/1>CONTENT >>> $ send -a >>> amqp://0.0.0.0:5672/my_**address/another<http://0.0.0.0:5672/my_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-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
