Re: Introducing Qpid Dispatch Router
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 There is a draft web page for it here: 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 $ recv amqp://0.0.0.0:5672/my_address/1 $ recv amqp://0.0.0.0:5672/my_address/another $ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT $ send -a amqp://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 -- Mitsuru Oka - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Introducing Qpid Dispatch Router
On 09/16/2013 09:57 PM, Ted Ross wrote:
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
$ recv amqp://0.0.0.0:5672/my_address/1
$ recv amqp://0.0.0.0:5672/my_address/another
$ send -a amqp://0.0.0.0:5672/my_address/1 CONTENT
$ send -a amqp://0.0.0.0:5672/my_address/another CONTENT
You can also run a similar example using the qpid::messaging examples
(assuming amqpc.so loaded and libqpid-proton found):
drain -f --connection-options {protocol:amqp1.0} abc
drain -f --connection-options {protocol:amqp1.0} abc
drain -f --connection-options {protocol:amqp1.0} xyz
spout --content one --connection-options {protocol:amqp1.0} -P
x-amqp-to=abc ignored
spout --content two --connection-options {protocol:amqp1.0} -P
x-amqp-to=xyz ignored
At present the router works off the 'to' field in the message which is
not set by default for the qpid::messaging library, rather than the
target address for the sender link.
Also, the address format that qpid::messaging uses treats an unquoted
'/' as the divider between node and subject, so if you want to use the
exact same addresses as in Ted's example above you need to ensure they
are quoted e.g. drain -f --connection-options {protocol:amqp1.0}
'my_address/1', so that the whole is taken as the source.
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.
The same behaviour should be seen.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: Introducing Qpid Dispatch Router
On 09/25/2013 09:20 AM, Gordon Sim wrote: On 09/25/2013 02:14 PM, Ted Ross wrote: 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. What about selective subscriptions e.g. sub-topic matching or wildcard matching? This is another interesting question. To the extent that the subscription selectors can be aggregated into a superset selector, I think Dispatch could do a pretty good job with this. For more sophisticated matching (i.e. content-based, etc.) you would probably want to put a broker into the mix. 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. That is like shared subscriptions in qpidd (but obviously more distributed). Yes, this is possible with qpidd by fanning-out to multiple queues (one per group) and then having the group members all subscribe to the same queue. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
New Fedora package: python-qpid_messaging
The Swigged bindings have been packaged and are now available on Fedora Linux as python-qpid_messaging. I've built for Fedora 18, 19 and 20 as well as Rawhide. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpxP5r7vcLqO.pgp Description: PGP signature
RE: Qpid threads' scheduling class and priorities
Hi Chris, No, there's no means to specify thread class/priority at this time. -Steve -- Steve Huston, Riverace Corporation Total Lifecycle Support for Your Networked Applications http://www.riverace.com -Original Message- From: cjl...@san.rr.com [mailto:cjl...@san.rr.com] Sent: Wednesday, September 25, 2013 7:05 PM To: users@qpid.apache.org Subject: Qpid threads' scheduling class and priorities Hi all, We have an application in which application threads are likely to be placed in the POSIX SCHED_FIFO real-time scheduling class on Linux with assigned priorities. Historically speaking we've tuned I/O-related threads to have the highest priorities, though in this case much of the I/O is happening in application threads created by the Qpid Messaging library and/or threads in the Qpidd C++ broker itself (since the broker is likely to be co-located with the application in our case). The concern is that our real-time application threads are likely to (inadvertently) starve Qpid. Currently is there any means to specify thread scheduling class/priority for threads created by the Qpid Messaging library or Qpidd C++ broker? After searching I don't think this topic has come up before in the mailing list. Regards, Chris Love - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
