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

Mon Mar 28 18:19:18 BST 2011

It's not completely invisible, but it's a pretty good solution all in all.

Does it suit the target use-case?

-Steven

On 28 March 2011 17:50, 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/20110328/e91b2d51/attachment.htm>