qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Queue/Route persistence with C++ broker restart
Date Wed, 22 Jun 2011 12:02:29 GMT
On 06/21/2011 02:05 PM, Phil Brown wrote:
> I am looking at creating a route between either an exchange (or a queue) on
> one C++ Broker to an exchange on another C++ Broker.  What is import for me
> is that this route survives either or both Broker's being restarted.  Is
> this possible?

Yes, provided you have a store plugin installed you need only specify 
that the route be durable.

One further consideration is whether you can tolerate message loss if 
either broker restarts. If not then the messages would need to be marked 
durable and you would need the route to have a durable queue as its 
source (rather than an exchange). You would obviously also want queues 
handling these messages downstream to be durable.

> If so can the route be created via the messaging API?

Yes, though it is a little involved[1]. The routes are created by 
sending map-messages to a special address (this is how qpid-route works 
also, though it uses an older format for the messages).

You need to first create a connection (or 'link') between the two 
brokers using the 'connect' method on the broker. You can then create a 
route (or 'bridge') over that link from a given queue or exchange on the 
source broker to an exchange on the destination broker. You do this 
using the 'bridge' method on the link object you just created, whose 
name is '<host>,<port>'. These details are defined by the management 
schema available in svn and also in source distributions[2]

I've attached a simple example that creates a durable route between 
amq.direct instances on two brokers for the key my-key (i.e. all 
messages sent to the amq.direct exchange on broker localhost:5673 with 
routing-key/subject my-key will be received my a subscriber to the 
equivalent exchange on localhost:5672).


[1] I hope that this aspect of the schema can in future be simplified 
quite a bit.


View raw message