[rabbitmq-discuss] Shovel bug? Consumer hangs after network failure.

[Øyvind Tjervaag]

Hi!

On Jan 20, 2011, at 11:45 PM, Matthew Sackman wrote:

> 
> Yes, this is largely to be expected. Consuming is an asynchronous
> activity and the Rabbit1 -> Rabbit2 shovel is just consuming from queues
> on Rabbit1. Until the socket is closed by the kernel, it won't
> necessarily notice that Rabbit1 has gone down. TCP timeouts can
> sometimes be quite long. So, I would recommend that you turn on
> heartbeats on that shovel. Unfortunately, looking through the source, I
> see there is no way to turn on heartbeats. Sigh. I'll file a bug and get
> that added.

Thanks! Figured something like this was happening.

> Writing to a socket rather than reading from it is much more likely to
> prompt an error quickly. Thus if you make your Rabbit1 -> Rabbit2 shovel
> a shovel running in Rabbit1 (i.e. Rabbit1 is pushing to Rabbit2 rather
> than Rabbit2 pulling from Rabbit1 as it is currently) then you should
> find that's more reliable and copes without the addition of heartbeats.

Yep, that's what I've done to work around the problem, and it seems to be 
working nicely :)

Also, the shovel doesn't seem to recreate the queue it was subscribing to if 
someone deletes it (for example from the management plugin). Should it?

Øyvind