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.
-Ted
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" <[email protected]>:
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 <[email protected]>:
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:
[email protected].**org<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
