<div class="gmail_quote">On Mon, Jan 23, 2012 at 23:57, dnsplus <span dir="ltr"><<a href="mailto:developer@dnsplus.net">developer@dnsplus.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>Thank you for all this. If I were inclined to use central and remote</div>
exchanges/brokers, then SHOVEL is the missing piece I have been looking for.<br>
However ... oh, the overhead with maintaining it all !<br></blockquote><div><br></div><div><span style="font-family:'trebuchet ms',sans-serif">Yes, I mentioned federation but in this context shovel is pretty much the same thing, although perhaps a little lighter than federation. Going down the route of several brokers, indeed, I see it becoming a pain quite soon.</span></div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I suppose I am inclined to go with a Central Broker and have remote<br>
consumers, and was wondering if someone might convince me otherwise.<br>
However, this has not yet happened.<br></blockquote><div><br></div><div>Perhaps some guys of the dev team can shed some light given their greater experience.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Seeing as how my application is more of a "task distribution and management<br>
system" where all sites are processing the same tasks (with RabbitMQ making<br>
sure that the tasks are received), it has occurred to me that I might want a<br>
database component at the central data center as well. I am working on a<br>
conceptual workflow to flush this idea out.<br></blockquote><div><br></div><div>I never used it personally, but if you're going to require a central store anyway you may consider some messaging solutions that come with the storage itself, after all according to what you describe you would be leveraging just a very small part of what RabbitMQ provides. For instance MS SQL Server ships with a built-in message broker, I don't know how it works but it may be worth investigating, and I'm sure other storages provide that as well. Some googling of "distributed work queues" may turn up something interesting too.</div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I keep coming back around to keeping as much intelligence as possible at<br>
Central, and keeping the consumer side as lean as I can.<br>
<br>
Thoughts ?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
View this message in context: <a href="http://old.nabble.com/Architecture-Question%3A-2-Brokers%2C-or-Not-2-Brokers---tp33189279p33191832.html" target="_blank">http://old.nabble.com/Architecture-Question%3A-2-Brokers%2C-or-Not-2-Brokers---tp33189279p33191832.html</a><br>
</font></span><div class="HOEnZb"><div class="h5">Sent from the RabbitMQ mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<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>