[rabbitmq-discuss] Shovel failover

[Laing, Michael P.]

Is the new failover scheme described somewhere? Couldn't find it.

Some of my configurations rely on shovels being set up differently for
each node in a cluster and that the shovel will stick to the node on which
it is configured.

The reason for these configurations (backup strategy to compensate for
partitioning) may have become moot nowŠ

However, I have gotten pretty used to the shovel just being a
straightforward, well-behaved application on a single node, driven by that
node's configuration. If it now jumps around among nodes in the cluster
automatically then it is no longer straightforward - let's hope it is
still well-behaved!

-ml

On 5/2/13 9:56 AM, "Tim Watson" <tim at rabbitmq.com> wrote:

>On 2 May 2013, at 11:29, Jon Bergli Heier wrote:
>
>> Hello, after upgrading to RabbitMQ 3.1.0 my shovels doesn't seem to
>>reconnect automatically. I don't have reconnect_delay set, so I'm
>>assuming they should use the default, which is 5 seconds according to
>>the shovel docs (http://www.rabbitmq.com/shovel.html).
>
>I've just checked and the default reconnect delay is still set to 5
>seconds.
>
>> The shovels are on non-clustered brokers, connecting to a two-node
>>cluster.
>
>
>Hmn. If the shovels were clustered then it's possible a named shovel's
>configuration from one node could override the other (due to the way in
>which individual shovel workers fail-over in 3.1), but you say they're
>not clustered. Hmn. I'll have a quick go at reproducing this, but AFAICT
>there's no reason they shouldn't be attempting to reconnect. Unless the
>reconnect_delay is being overridden somewhere?
>
>Cheers,
>Tim
>_______________________________________________
>rabbitmq-discuss mailing list
>rabbitmq-discuss at lists.rabbitmq.com
>https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss