On 03/27/2014 03:33 PM, Chris Richardson wrote:
Hi mailinglist,
I'm trying to set up a broker federation topology with a server and (for
prototyping) two clients and I need to send messages from one client to the
other, routed via the server broker since the clients will be
firewalled/NATed and can not communicate directly. My understanding is that
the way to do this is with dynamic routing and I've followed the discussion
on the following thread with some success:
http://qpid.2158936.n2.nabble.com/Dynamic-routing-between-disconnected-exchanges-td7598100.html.
That article describes three nodes A, B and C, and relaying from node A to
C via B.
So far so good - I can use "drain" on node C's test-topic/C
exchange/routing key and "spout" to write to node A's test-topic/C
exchange/routing key and the message is transferred via the "server" (node
B).
The problem I have is that this setup relies on TCP links being established
in both directions between each node. In my client-server scenario this is
clearly not possible and with the network restriction in place the dynamic
routing fails. As the documentation states, "A dynamic exchange route is
always a pull route. It can never be a push route.". Does this mean that
the underlying broker link must be established in the same direction as the
route, or is there some way to override this or get the route from the
server to utilize the existing link from the client? Solutions involving
VPNs and tunnels are "not allowed".
What are the message flows here, i.e. what 'topics' or 'queues' will be
involved? Do you really need dynamic federation or could a static
configuration work?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
