Hello Tor Rune
Re: "
We are particularly interested in your comment "...qpidd (which supports
establishing basic AMQP 1.0 links to/from other processes)..."
"
I'm pretty sure that this relates to some features recently added by
Gordon to qpidd for AMQP 1.0 the main place that they have been referred
to currently is in the management-schema.xml in
<qpid>/qpid/cpp/src/qpid/broker/management-schema.xml
I think that the things you are after are the Domain and Outgoing
Management Objects. Unfortunately I'm afraid that I've not yet got round
to playing with these myself and I don't believe that there is any
documentation available on how to use them yet so you might have to wait
for Gordon to give a definitive response, however I have played with the
Topic and TopicPolicy objects and the approach should be similar (I
can't try it out for you at the moment I'm afraid 'cause my build is a
bit broken)
For adding Topics (a Topic is a sort of pseudo-node and allows one to
provide configuration for subscription Queues).
The following syntax will create a topic called fanout that uses the
exchange amq.fanout and
creates circular (ring) subscription queues of size 1000000.
qpid-config add topic fanout --argument exchange=amq.fanout \
--argument qpid.max_size=1000000 --argument qpid.policy_type=ring
qpid-config list topic
gives:
Objects of type 'topic'
name durable properties exchangeRef
============================================================================================
fanout False {u'qpid.max_size': u'1000000', u'qpid.policy_type':
u'ring'} amq.fanout
Now that's not directly going to answer your question, however I think
that the mechanism you'd need is analogous, that is to say
qpid-config add domain --argument name <name> --argument url
<destination connection URL> --argument username <username> --argument
password <password>
As I say I've not actually tried this so YMMV and I'm not totally sure
what the url relates to, but I'd guess that it might simply be the
<host>:<port> of the destination AMQP container.
In order to get messages to the destination container from the broker I
*think* that you need to specify the domain in the address, so for
example if you had set up a queue myqueue on the destination broker and
decided to give it the domain mydomain I believe that you'd use the
address myqueue@mydomain when you sent the message to the source broker.
I'm sure that I read that somewhere - but I'm darned if I can remember
where.
Sorry that this is somewhat second hand and hearsay and hopefully
someone will be able to give a more definitive answer, but it might help
to get you started.
The domain stuff was put in place for AMQP 1.0 and I'm not sure if it
supports AMQP 0.10, my guess is probably not, AMQP 1.0 is quite
different to AMQP 0.10, in particular it is a peer to peer protocol and
primarily specifies how to establish links between AMQP 1.0 nodes. This
is a lot less limiting than AMQP 0.10 and is one of the reasons why
things like the dispatch router can now be created. It also provides
much better interoperability, so whereas in the past you might have had
to build a bespoke message bridge to connect say a Qpid broker to an
ActiveMQ broker with AMQP 1.0 I think that you should be able to
configure a Domain to allow you to directly connect.
Regards,
Frase
On 04/04/14 11:01, 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.
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?
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?
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]
Den 01. april 2014 13:27, skrev Chris Richardson:
Thanks very much Gordon. I have had some previous endeavours with the
dispatch router (in fact I started there before switching to the broker)
and will return to that plan of attack.
I think we will still need brokers in this topology in order to queue
messages for offline clients, otherwise the router would be the better
option. I look forward to future releases with the improved broker
integration!
/Chris
2014-03-28 15:52 GMT+00:00 Gordon Sim <[email protected]>:
On 03/28/2014 01:36 PM, Chris Richardson wrote:
Ah, now we are really opening Pandora's box! ;)
The term "client" here is actually quite a simplified term and actually
refers loosely speaking to a system managing a number of products on
that... client. Both the management system and the products should be
individually identifiable and addressable over AMQP; it should also be
possible to address them in groups. Furthermore the client system will
typically be connected over an unreliable network link and the messaging
system is expected to guarantee delivery. Given these constraints I
envisage each client system having at least one local exchange (and queues
to cope with disconnections), and most probably it/they will be topic
exchanges to support the addressing functionality. However I'm very new to
the AMQP routing and addressing concepts so I may be misguided.
Even with dynamic routing, you need to manually set it up per exchange
(what it then does is manage the set of routing keys in use for
inter-broker links, based on the interest expressed by subscriptions).
If you are using topic exchanges you might be able to simply forward all
messages for a given exchange through from A->B->C, which you can do by
simple static routes per exchange (not actually any more management
operations than making setting up dynamic routing for the same exchange).
The static routes *should* work ok with 'push' routes (though I will warn
that those are not as well used), allowing you to choose the direction of
the TCP connection independent of the direction of message flow.
Also, without wanting to confuse the picture too much, I'll just note in
passing that the recent developments around AMQP 1.0 may be of some
interest to your scenario. First off there is the 'Dispatch Router'
component. This is superficially similar to a broker, but it only forwards
messages it never accepts responsibility for them. It could be used as the
'server' broker in your setup, with the 'clients' both connecting in and
sending or receiving to/from that. You could use this in conjunction with
qpidd (which supports establishing basic AMQP 1.0 links to/from other
processes), or depending on your use case there may not be a real need for
brokers at all.
(A future release of the router will be able to establish links out to
other 1.0 capable brokers (or other types of 'thing') itself making it even
more flexible/powerful).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
