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

Tue Mar 29 15:26:10 BST 2011

Hi Matthew

"....shovel plugin" sounds very interesting and from what you've
described....exactly what I'm after, thank you!

I'll look into it tonight and update the discussion with any success!

Bruce

On Mon, Mar 28, 2011 at 5:50 PM, Matthew Sackman <matthew at rabbitmq.com>wrote:

> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110329/1986fac6/attachment.htm>