On 8 April 2014 15:41, Gordon Sim <g...@redhat.com> wrote: > <snip> > >> We are particularly interested in your comment "...qpidd (which supports >> establishing basic AMQP 1.0 links to/from other processes)..."; Chris've >> tried things like adding a link from a broker to a router with >> "qpid-route link add..." but this produces errors relating to SASL on >> the router side and version errors on the broker side. We haven't >> pursued this further as we're not sure this is how it's supposed to >> work. Is there any documentation or examples you could refer us to? >> > > In the case of qpidd this is indeed (as Fraser pointed out) via a slightly > different mechanism than the existing 'federation' feature (which is more > tied to AMQP 0-10). > > Specifically you would create a 'domain' to represent the router (or > whatever external AMQP 1.0 compliant process you wish to connect to), then > create 'incoming' or 'outgoing' links for messages to be transferred over. > > I'm afraid although I've described it on this list a few times, it isn't > properly documented at all yet, sorry! I should also point out that its a > relatively raw 'feature' at present. Specific known limitations at present > include no automatic reconnect for broker established 1.0 connections and > no mechanism for preventing message looping. > > However as an example, say you swapped Dispatch Router in for Broker B, > you would then create a 'domain' for that on both Broker A and Broker C, > using qpid-config (on latest qpid release): > > qpid-config add domain BrokerB --argument url=public-ip > > or qpidt test tool[1] on earlier releases: > > qpidt create domain url=public-ip > > (You can also specify sasl details if you want authentication, but as > dispatch router doesn't yet support that, I've left it out). > > Then you would either add 'incoming' or 'outgoing' links from/to that > domain, e.g. on BrokerA > > qpid-config add outgoing my-test-link source=abc target=def > > and on BrokerC > > qpid-config add incoming my-test-link source=def target=xyz > > which should cause messages sent to abc on BrokerA to be received by > subscribers to xyz on BrokerC, with messages queued in abc and xyz. >
I've set this scenario up on my test system (I had to add "--argument domain=BrokerB" to the "qpid-config add incoming|outgoing ..." commands...) and it looks promising, except if I understand correctly there is no queuing on the relaying node since it's a dispatch router. Unfortunately we absolutely need this. > (You can also send/receive to/from e.g. my-random-address@BrokerB which > will dynamically create the links as needed between A/C and B. However in > this scheme you wouldn't get any store and forward ability, so there may > not be any value to A and C being qpidd instances at all). > > > But to sum up, are there at all any "best practise" ways to solve >> "dynamic routing" for spontaneously connected clients without public IPs >> with today's (or tomorrow's :-) ) tool-set? >> > > You should be able to set this up using the 'old' federation and qpidd, > though it would only use AMQP 0-10. You would need to use push routes as > well as the standard pull routes. However even with dynamic routing you > would need one route in each direction per exchange, and the same would > apply to 'static' routes if you didn't need the traffic to be optimised to > avoid unnecessary transfers[2], and static routes do allow push routes > (where the flow of messages is to the process that originally established > the tcp connection). I think this is the best solution today if you have to > have some store-and-forward ability (i.e. allow senders to forget about > messages they sent and rely on the messaging intermediaries to keep trying > to deliver until successful). > > Tomorrows solution would I think be based either on the new mechanisms > being added to Dispatch Router, allowing store-and-forward capability to be > added for addresses through an associated broker to which the router will > manage connections, or on adding reconnect/redelivery capabilities to > messenger. You are just a little bit ahead of us at present! We're obviously very interested in these next developments. Can you give us a rough idea of when we can hope to see these implemented, at least in beta? Thanks, Chris
