Hi Matthew<div><br></div><div>"....shovel plugin" sounds very interesting and from what you've described....exactly what I'm after, thank you!</div><div><br></div><div>I'll look into it tonight and update the discussion with any success!</div>
<div><br></div><div>Bruce</div><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Mon, Mar 28, 2011 at 5:50 PM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Bruce,<br>
<div><div></div><div class="h5"><br>
On Fri, Mar 25, 2011 at 12:05:46PM +0000, bruce bushby wrote:<br>
> I was wondering what others are doing with regards to "queuing" local<br>
> messages for deliver when the network is available.<br>
><br>
> From my limited experience playing to "rabbitmq-c client" and Python "pika",<br>
> their focus is the ability to deliver a message immediately and report an<br>
> error if they cannot contact the server.<br>
><br>
> Implementing messaging from a M2M platform, there will be times when there<br>
> is no communication between the client and the server...but the application<br>
> may still want to submit messages which should be queued until such time as<br>
> the "local queue" so to speak can contact the server and delivery the<br>
> messages.<br>
><br>
> In summary, leaving the "retry/retransmission" of message to the<br>
> messaging infrastructure...rather then have the application monitor/poll<br>
> connectivity to the server.<br>
><br>
> Is something like this possible?<br>
<br>
</div></div>Yes. What we recommend is that you have Rabbit installed locally, and<br>
then configure it with the shovel plugin which will periodically try to<br>
connect to the "downstream" Rabbit and send the messages out. One nice<br>
way to configure this is to have the same exchange name on the local and<br>
remote broker, but on the local, it's a fanout. On the remote it can be<br>
whatever you need it to be. Then, the shovel, local, can just create a<br>
single queue and catch everything sent to the local exchange. When it<br>
connects to the downstream remote broker, it'll republish the msgs to<br>
the same exchange name, but because the type of the exchange there can<br>
be different, all sorts of other routing decisions can take place as<br>
needed. I.e. it ensures that the local broker topology can be as simple<br>
as possible (one exchange, one queue, one shovel).<br>
<br>
Matthew<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<div><div></div><div class="h5"><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>