[rabbitmq-discuss] "local queue" ...."remote queue"

[Matthew Sackman]

Hi Bruce,

On Fri, Mar 25, 2011 at 12:05:46PM +0000, bruce bushby wrote:
> I was wondering what others are doing with regards to "queuing" local
> messages for deliver when the network is available.
> 
> From my limited experience playing to "rabbitmq-c client" and Python "pika",
> their focus is the ability to deliver a message immediately and report an
> error if they cannot contact the server.
> 
> Implementing messaging from a M2M platform, there will be times when there
> is no communication between the client and the server...but the application
> may still want to submit messages which should be queued until such time as
> the "local queue" so to speak can contact the server and delivery the
> messages.
> 
> In summary, leaving the "retry/retransmission" of message to the
> messaging infrastructure...rather then have the application monitor/poll
> connectivity to the server.
> 
> Is something like this possible?

Yes. What we recommend is that you have Rabbit installed locally, and
then configure it with the shovel plugin which will periodically try to
connect to the "downstream" Rabbit and send the messages out. One nice
way to configure this is to have the same exchange name on the local and
remote broker, but on the local, it's a fanout. On the remote it can be
whatever you need it to be. Then, the shovel, local, can just create a
single queue and catch everything sent to the local exchange. When it
connects to the downstream remote broker, it'll republish the msgs to
the same exchange name, but because the type of the exchange there can
be different, all sorts of other routing decisions can take place as
needed. I.e. it ensures that the local broker topology can be as simple
as possible (one exchange, one queue, one shovel).

Matthew