Cleaning up queues and exchanges on RabbitMQ

During my day to day work, we are running a number of integration tests against various queuing systems. In order to have a clean slate after and/or before each integration test run, we need to clean up the queueing system. With RabbitMQ cleaning up, the broker is usually very simple. You can use the built-in RabbitMQ Management Console (rabbitmqctl) and issue the following commands:

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app

Attention: This not only cleans the queue, it actually deletes them.

Read more about the command line tool for managing a RabbitMQ broker here. The problem of this approach is already stated in the documentation:

Removes the node from any cluster it belongs to, removes all data from the management database, such as configured users and vhosts, and deletes all persistent messages.

So in essence all configuration such as clustering, users, vhosts etc. is bluntly removed alongside with the queues and messages. While this can be the desired approach in some scenarios, it might not be if we want more fine-grained control about what is removed or when we want to preserve the cluster configuration, users, vhosts etc. *1

So how can we control what we want to remove? There are essentially two approaches:

The problem of most of the client libraries is that they are mainly built for interaction with RabbitMQ directly and its administrative tasks that come with those interactions like deleting one queue, deleting one exchange but not for bulk deletes of queues and exchanges. Therefore, I had to rule out client libraries. *2

The second approach is using the HTTP API of RabbitMQ which can be enabled by installing the RabbitMQ Management Plugin. Let us see what the management plugin allows us to do

The rabbitmq-management plugin provides an HTTP-based API for management and monitoring of your RabbitMQ server, along with a browser-based UI and a command line tool, rabbitmqadmin. Features include:

  • Declare, list and delete exchanges, queues, bindings, users, virtual hosts and permissions.
  • Monitor queue length, message rates globally and per channel, data rates per connection, etc.
  • Send and receive messages.
  • Monitor Erlang processes, file descriptors, memory use.
  • Export / import object definitions to JSON.
  • Force close connections, purge queues.

As you can see I cheated a little bit when I introduced the two approaches. The management plugin not only has an HTTP API but also a browser-based user and a command line interface. But as I wanted to integrate the cleanup routines into the existing integration tests written in C#/.NET the HTTP API better fit my purposes. After the management plugin is installed and enabled with

abbitmq-plugins enable rabbitmq_management

You can do all your HTTP requests against http://server-name:15672/api/ to do all necessary management tasks. In fact, if you browse to this endpoint by using a browser you get a good documentation about what the API provides over HTTP and how to interact with it. The latest documentation is also available online.

Because this post is approaching a certain length, I’m going to show the C# code and alongside with that a few explainings in another installment. In the meantime take a look at the HTTP API of RabbitMQ. This knowledge is going to serve you well for the next more technical post. Keep your rabbits nurtured until then!

*1: Of course you could also setup RabbitMQ inside docker, apply the necessary configuration, commit that to docker and the just reset RabbitMQ to its previous state by using the docker commands. But this is not the topic of this post.

2*: To be fair only had a brief overlook over the other client libraries but my research was primarily focused on the official .NET client library. So if you look closer, you might find one in your preferred language which is more capable.

Feature image by Tomas Baugis.

About the author

Daniel Marbach


By Daniel Marbach

Recent Posts