On 04/04/2014 11:01 AM, Tor Rune Skoglund wrote:
Hi Gordon,
I'm working with Chris on this, as he is off-line for the time being, I
post some additional questions:
Could you please expand on how the dispatch router could be incorporated
into our topology? Specifically, we don't see how to set up a route
between brokers via a dispatch router.
As Ted mentioned in his post, the router is not yet able to do this (and
in any case, depending on topology, you might sometimes want the
connections established in the other direction anyway).
However providing the broker used can establish connections (and links
on them) to some external AMQP 1.0 compliant process, you should be able
to get them to connect to the dispatch router.
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.
(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!
Simplified setup:
[Machine A/Broker A] [Machine C/Broker C]
[ Private IP ] [ Private IP ]
[Out and In Queues ] [Out and In Queues ]
/\ /\
|| ||
\/ \/
[ Priv IP GW ] [ Priv IP GW ]
[ NAT ] [ NAT ]
["Random" pub IP ] ["Random" pub IP ]
/\ /\
|| Unstable connections (e.g. 3G) ||
\/ \/
_________________________________________________
[ S e r v e r P u b l i c IP ]
[ Out and In Queues per Machine ]
[ S e r v e r B r o k e r B ]
[_________________________________________________]
The "IP analogy" would be that Broker A would not know the route to C it
just sends the message off to B (the "default route"), and lets B
forward the message to the right outgoing queue for C.
Best regards,
Tor Rune Skoglund, [email protected]
[1]
http://svn.apache.org/viewvc/qpid/branches/0.24/qpid/cpp/src/tests/qpidt?view=markup
[2] 'dynamic' routes only transfer messages for which there is an
interest subscriber on the other end
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
