[rabbitmq-discuss] Proper protocol for dealing with crash dumps?

[Alex Zepeda]

On Mon, Oct 08, 2012 at 10:06:48PM +0100, Matthias Radestock wrote:

> So, just to be clear, you have connections that are "stuck" but do show 
> up at the destination with a non-zero heartbeat/timeout? That's odd.

The devices send messages to a local queue (shovel) and other messages 
directly to a remote rabbit server.  Some of these devices are able to
send out the remote messages, but the messages in the shovel queue
aren't being sent.  The last time I checked a device in this state,
I ran the command: rabbitmqctl eval 'rabbit_shovel_status:status().'

Which indicated to me that the shovel was active.  I have not checked
the remote rabbit instance (yet).  All of the shovel configurations
should be identical.

If/when I succeed in logging into one of these stuck devices, are
there any pertinent commands I should run?

> > The shovel config looks like so:
> >
> > 		{shovel_one
> >                      [ {sources,
> >                          [ {broker, "amqp://"} ]}
> >                      , {destinations,
> >                          [ {broker, "amqp://user:password@remote.hostname?heartbeat=5"} ]}
> >                      , {queue, <<"queue_name">>}
> >                      , {ack_mode, on_confirm}
> >                      , {publish_properties, [ {delivery_mode, 2} ]}
> >                      , {reconnect_delay, 35}
> >                      ]}
> >                  ]}
> >      ]}
> 
> You can't got a prefetch_count set. This will cause all messages to pile 
> up in memory in the event of a connection getting stuck.

Should I set prefetch_count?  The queue in this case is durable, and
messages should be delivered to the local queue with delivery_mode = 2.

- alex