Verifying Connections and Queue Activity

When you run the examples here. the code silently connects, delivers the message, and disconnects. To verify that it did something, log into the RabbitMQ Management UI in the Browser tab on your deployment, and select the Exchanges tab.

2242

An example Exchanges tab in the RabbitMQ Admin panel.

If you were following one of the connection examples in this documentation, there should be a "postal" exchange there, which the code created.

If you are looking to verify your own application, there should be an exchange named whatever your code specifies.

Comfirm and Consume a Sample Message

Create a New Queue

To confirm that the message arrived, create a queue to consume the message.

  • Go to the Queues tab
2220

Queues tab in the RabbitMQ Admin panel

  • Click on Add a new queue and specify a name, for example fred. This is the queue that will consume the sample message from the exchange.
2158

Creating a new queue

Binding a Queue to an Exchange

  • Go back to the Exchanges tab and select the postal exchange (or whatever the name of your exchange is). Select Bindings.
1260

The details of the postal exchange.

  • Under Bindings select to queue and enter "fred" for the queue name and enter "tributes" as the routing key. (Or enter the information from your example queue and routing key.)
1426

Adding a queue and routing key to an exchange.

  • Click Bind, and return to the sample code or your application to send a message.

Getting a Message from the Queue

  • In Admin UI, go to the Queues tab and select the fred queue.
2478

The details of the fred queue.

  • Open up the Get Messages panel
1002

The Get Messages panel before consuming the message.

  • Click Get Message to display the message
1260

The Get Messages panel after consuming the message.

Any messages sent before a queue was bound to the exchange are discarded automatically as they could not be routed. RabbitMQ has a mechanism to catch unroutable messages called Alternate Exchanges for special cases, but it is generally best to ensure everything is routed in the messaging architecture.

In this case, the message stays in the queue even though getting a message is a destructive act. This is because, on the Get Messages panel, the default setting is to re-queue the messages after they are retrieved.


Still Need Help?

If this article didn't solve things, summon a human and get some help!