Another question on Dispatch router is there. Could you show me an example of request-reply/response pattern via Dispatch router using proton messenger based sender and receiver? I tried proton client/server python example, but the client couldn't receive reply message from server.
$ dispatch-router -c qpid-dispatch.conf $ ./server.py amqp://0.0.0.0/topic $ ./client.py amqp://0.0.0.0/topic subject server output: amqp://b0f56a1c-573c-42e0-8c6f-46d5735b2301/replies Dispatched subject None client output: <nothing and blocking> Thanks, Mitsuru Oka 2013/9/26 Ted Ross <[email protected]>: > 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] > -- Mitsuru Oka --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
