If my understanding is correct, you can't actually look at messages in the rabbit queue without taking them out and putting them back in. There's no way to use rabbitmqctl to inspect a queue.
In some debugging contexts, knowing what is currently in the queue is very useful. Is there a way to get at the messages? Also, what is it about the design of Rabbit that makes this process cumbersome?
You can certainly look at the contents of a queue in RabbitMQ, or any AMQP broker, for that matter. Just consume messages but don't acknowledge them. Once you close the channel the messages will be available for consumption by your 'real' consumers. Keep in mind that doing so might affect the ordering of messages in the queue which you inspect.
Also, the web management plugin offered by RabbitMQ allows you to view the contents of messages from the web interface. If you're trying to debug your system, it's a very helpful tool.
You can use Queue Viewer (https://www.queueviewer.com). It requires that RabbitMQ's management plugin is enabled.
This is old, but just for anyone interested in this. By visiting the
Queues
you have a list for all the queues of the broker.Press any queue you are interested and scroll down to find this section
The really important option to set here is the
Requeue
option. If is set toYes
, this operation will consume the message, so you can read it, but it will requeue it, so it won't be lost.I have not used this personally yet but I saw RabbitMQ's management plugin that I thought allowed you to monitor the queue.
http://www.rabbitmq.com/management.html
There's no sane way to look at a queue, but maybe monitoring what goes in is a sufficient substitute. To do this, you need to implement a man-in-the-middle monitor. This requires cooperating clients: you need to teach either all senders or all receivers to use a different exchange.
Suppose you want to monitor messages to exchange "foo". You create a (direct) exchange named "foo-in" (or whatever), set up "foo" as an alternate exchange for "foo-in", and teach all your senders to send their messages to the "foo-in" exchange instead of "foo".
Your queue monitor then needs to listen to "foo-in", and to re-publish all messages to "foo". Whenever the monitor is not running, rabbitmq will route them to "foo" by itself; the performance penalty for this is negligible.
This is a rabbitmq extension. See http://www.rabbitmq.com/ae.html for details on how alternate exchanges work. Of course you can use "foo" and "foo-out", respectively, if that's easier to do in your setup.
Monitoring a specific queue (again: queue input, not output) is easier but again requires changing the client (or the code which creates your queues, if they're persistent). Set up a fan-out exchange, bind the client's queue to that, and then bind the exchange to the original messages source. This is another rabbitmq extension; see http://www.rabbitmq.com/e2e.html. Your monitor simply needs to bind to that exchange and will get copies of all messages sent to the client's queue.
There is a "Get Messages" section for each queue in the management API. However this causes the message to be consumed and hence is a destructive action. We can re-queue this message to the queue only at the expense of sacrificing the ordering of messages [for rabbitmq versions < 2.7.0].
A more viable alternative would be to use the firehose tracer, http://www.rabbitmq.com/firehose.html [for rabbitmq versions> 2.5]. This essentially publishes the message to a different exchange (amq.rabbitmq.trace) just for debugging purposes.
Here is another GUI written on top of firehose for better visibility, http://www.rabbitmq.com/blog/2011/09/09/rabbitmq-tracing-a-ui-for-the-firehose/