<div class="gmail_quote">On Mon, Feb 8, 2010 at 6:42 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@lshift.net">matthew@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Peter,<br></blockquote><div><br></div><div>HI Matthew,</div><div><br></div><div>Thanks for joining the thread.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Mon, Feb 08, 2010 at 06:29:45AM -0600, Peter Fitzgibbons wrote:<br>
> Could you direct me to an example of how to set up a "stand alone" shovel?<br>
<br>
</div>The shovel does not run stand-alone - it is a plugin. The old shovel<br>
that you found at [1] is very old, unsupported and deprecated. The new<br>
shovel that Matthias linked to is the "way forward" ;)<br></blockquote><div>Got it</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> The only example[1] i found is demonstrating an embedded shovel as rabbitmq<br>
> plugin. �This seems to be my degenerate case all over again. �No?<br>
<br>
</div>Nope. To use your terminology, if you have rabbitP, which is local to<br>
producerP, then you then have the option to run the shovel inside<br>
rabbitP. This is configured to know about rabbitA, rabbitB� and so if<br>
any of those rabbits go down, the shovel will automatically try to<br>
reconnect, trying all the rabbits it knows about until it finds one that<br>
works. Whilst the shovel is trying to find a rabbit to connect to,<br>
messages queue up inside rabbitP, from producerP, in the normal way -<br>
the interruption is totally invisible to producerP.<br>
<div class="im"><br></div></blockquote><div>How is this different from configuring a rabbit cluster that includes my "local" node?</div><div>Matthias warned me that this is a degenerate case, where the cluster will struggle to support 10's (100's in a farm) of clustered servers.</div>
<div><br></div><div>To extend my understanding (and offer an opportunity to correct my understanding),</div><div>Shovel is preferred because the local rabbitP is not clustered, does not have to be "aware" of the cluster, and shovel has the proper failover routines to handle it when times get tough.</div>
<div><br></div><div>What about consumerA, consumerB, etc? �Are these theoretically expected to be "protected" from harm? �I think this question is pointing toward my potential misunderstanding of how consumer push or pull is handled.</div>
<div><br></div><div>Thanks for your time!</div><div><br></div><br clear="all">Peter Fitzgibbons<br>(847) 859-9550<br>Email: <a href="mailto:peter.fitzgibbons@gmail.com">peter.fitzgibbons@gmail.com</a><br>IM GTalk: peter.fitzgibbons<br>
IM AOL: <a href="mailto:peter.fitzgibbons@gmail.com">peter.fitzgibbons@gmail.com</a><br><br><br><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> [1]<br>
> <a href="http://hopper.squarespace.com/blog/2008/6/22/introducing-shovel-an-amqp-relay.html" target="_blank">http://hopper.squarespace.com/blog/2008/6/22/introducing-shovel-an-amqp-relay.html</a><br>
<br>
</div>Matthew<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="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br>