Avoid Doing These 4 Things with RabbitMQ

By Jim Liao
Feb 28, 2017

Avoid Doing These 4 Things with RabbitMQ

RabbitMQ might seem like the silver bullet that solves all your messaging problems, but take care not to misuse it. Otherwise you will be in for a lifetime of regret after you invested heavily in your solution. Here are 4 things that you should avoid doing with RabbitMQ.

1. Never leave the guest user account wide open

A default RabbitMQ installation create a guest user account that is also has administrator privileges. The older installations allow the guest account to be access from any remote machine, while newer installations restrict the access only from the local machine by default. For developers and technicians who wants to get the RabbitMQ installation up and running quickly, they tend to overlook the steps that need to be taken to harden the security of their RabbitMQ installation. One of those simple steps is to rename the password for the guest account or remove the guest account altogether and replace it with another administrator account. The default RabbitMQ account is ‘guest/guest’ for login and password. Anyone that knows this can wreak havoc on your RabbitMQ installation.

2. Never setup a RabbitMQ cluster across a Wide-Area-Network (WAN)

RabbitMQ cluster is a group of RabbitMQ instances, called nodes, that work in concert to provide high availability. The nodes use heartbeats to check if other nodes are online and healthy. After a few failed heartbeats fail to respond, that node is declared as disconnected. Message Queues resides only on the node that it is declared on and therefore when a message send to one node must be delivered to a queue residing on another node, its message content must be transferred from one node to the other. This data transfer is through the same TCP connection that is used by the health heartbeats. This is why RabbitMQ clusters must always be configure within a local network. Having a slow network connection between nodes in a RabbitMQ cluster can cause nodes to disconnect from each other because the heartbeats did not reach the node in time due to the connection being congested with transferring large message data.

3. Avoid sending large messages

Sending large messages might seem like a good idea at first because you don’t have worry about other technology stacks for transferring large data. Avoid transferring large images, audios, videos or file contents because it can slow down the message throughput and also increase the memory footprint. The connection between your RabbitMQ client and message broker all goes through the same network connection. Send large messages can saturate your bandwidth and cause other messages to be queued. In order to create a high message throughput system, you need to send lightweight messages whose content contains enough information to retrieve the actual larger content using protocols built for support large content transfers such as FTP, SCP and HTTP.

Sending large messages through RabbitMQ can also increase the footprint. For non-durable queues, this means that the message is keep in-memory which adds to the overall memory footprint. When RabbitMQ is under memory pressures, it will start writing those content to secondary storage such as a hard drive or SSD. This can result in unnecessary I/O that will slow down your overall system. It is even worst with durable queues which requires that messages be persisted to secondary storage as the messages are accepted into the message broker. Large messages create unnecessary I/O that can be avoided. Depending on the performance of your secondary storage, the message throughput can be greatly impacted by large messages.

Send large messages can also cause RabbitMQ clusters to fail sporadically because the same channel is used for sending health check heartbeats is also used for sending those large messages. When large amounts of data cause the heartbeats to be delayed too many times, the nodes inside a RabbitMQ cluster will disconnect from each other.

4. Avoid using RabbitMQ for realtime messaging

I wrote extensively in this article on why you should not use RabbitMQ for realtime messaging. Since RabbitMQ is good at sending and broadcasting messages, you might be tempted to use it for streaming real-time data. I would advise not to use RabbitMQ for that purpose due to the fact that it is not designed for real-time applications. Real-time data applications are based on time-sensitive updates and RabbitMQ does not guarantee this.

What can you do with RabbitMQ?

I have a 5-part video course on How to Improve Your Design and Architecture with RabbitMQ. In the course, you will learn how to harness the power to RabbitMQ to create reliable and scalable architectures and avoid mistakes like the ones I mentioned above.


* Email address will not be shared and only used for private communication.

Recommended Posts