[rabbitmq-discuss] Shovel bug? Consumer hangs after network failure.
oyvind at tjervaag.com
Fri Jan 21 11:00:41 GMT 2011
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?
More information about the rabbitmq-discuss