[rabbitmq-discuss] Fwd: Client-connection failover workarounds (ruby)

Peter Fitzgibbons peter.fitzgibbons at gmail.com
Mon Feb 8 15:22:32 GMT 2010


On Mon, Feb 8, 2010 at 6:42 AM, Matthew Sackman <matthew at lshift.net> wrote:

> Hi Peter,
>

HI Matthew,

Thanks for joining the thread.


>
> On Mon, Feb 08, 2010 at 06:29:45AM -0600, Peter Fitzgibbons wrote:
> > Could you direct me to an example of how to set up a "stand alone"
> shovel?
>
> The shovel does not run stand-alone - it is a plugin. The old shovel
> that you found at [1] is very old, unsupported and deprecated. The new
> shovel that Matthias linked to is the "way forward" ;)
>
Got it


>
> > The only example[1] i found is demonstrating an embedded shovel as
> rabbitmq
> > plugin.  This seems to be my degenerate case all over again.  No?
>
> Nope. To use your terminology, if you have rabbitP, which is local to
> producerP, then you then have the option to run the shovel inside
> rabbitP. This is configured to know about rabbitA, rabbitB… and so if
> any of those rabbits go down, the shovel will automatically try to
> reconnect, trying all the rabbits it knows about until it finds one that
> works. Whilst the shovel is trying to find a rabbit to connect to,
> messages queue up inside rabbitP, from producerP, in the normal way -
> the interruption is totally invisible to producerP.
>
> How is this different from configuring a rabbit cluster that includes my
"local" node?
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.

To extend my understanding (and offer an opportunity to correct my
understanding),
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.

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.

Thanks for your time!


Peter Fitzgibbons
(847) 859-9550
Email: peter.fitzgibbons at gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons at gmail.com




> > [1]
> >
> http://hopper.squarespace.com/blog/2008/6/22/introducing-shovel-an-amqp-relay.html
>
> Matthew
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://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/20100208/cee65a84/attachment.htm 


More information about the rabbitmq-discuss mailing list