[rabbitmq-discuss] RabbitMQ Shovel Connections

Matthias Radestock matthias at rabbitmq.com
Sun Nov 20 14:02:03 GMT 2011


Jelle,

On 17/11/11 13:39, Jelle Smet wrote:
> I still have the same issue going on. Here's a recap:
>
> * I have upgraded to the latest stable (2.7.0) Rabbmitmq on all
> nodes.
> * Messages which should be shoveled to a remote broker stay
> unacknowledged in the queue which Shovel is using as a source.
> * When restarting RabbitMQ containing Shovel after that all messages
> are shoveled correctly to their destination.
> * ack_mode has value "on_confirm", when changing this to "no_ack" all
> messages get lost.
>
>
> I must say that it's possible that small network interruptions
> happen, or occasional packetloss occurs... but that doesn't explain
> that restarting Rabbit, makes all messages arrive.

All the above observations are consistent with the network connection
having gone stale, i.e. there has been a network interruption but the
shovel hasn't noticed that yet. Depending on your OS / network setup it
can take hours for that to happen.

Try configuring heartbeats for the connections, which will allow rabbit
to detect this situation much more promptly. See the shovel readme for
how to do that.

> Here's my complete Shovel configuration

This looks ok except I'd suggest that you use "amqp://" instead of
"amqp://localhost". That way the much more efficient direct connection
is used, which also eliminates any possible network-related issues for
that hop.

> * Restarting RabbitMQ on that moment isn't possible.

That certainly shouldn't happen. Does 'rabbitmqctl report' work when 
rabbit is in that state? (NB: try running this *before* you attempt to 
stop rabbit).

> Killing is  required, often having to issue "epmd -kill"

epmd should have nothing to do with this. And killing epmd does not kill 
rabbit. Indeed epmd should refuse to stop if rabbit on that node is 
still running.

Regards,

Matthias.


More information about the rabbitmq-discuss mailing list