<div>It's not completely invisible, but it's a pretty good solution all in all. </div><div> </div><div>Does it suit the target use-case?</div><div> </div><div>-Steven<br><br></div><div class="gmail_quote">On 28 March 2011 17:50, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>></span> wrote:<br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">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>