VMware RabbitMQ Review

Helps to remove a lot of the complexities and create a loosely coupled codebase

What is our primary use case?

I am still comparing RabbitMQ and Kafka, but based upon the information I have gathered RabbitMQ is an awesome tool.

How has it helped my organization?

RabbitMQ will help to remove a lot of the complexities and create a loosely coupled codebase.

What is most valuable?

I like the high throughput of 20K messages/sec, and that it supports multiple protocols. The flexible routing is great as well.

What needs improvement?

The next release should include some of the flexibility and features that Kafka offers.

For how long have I used the solution?

Still implementing.

Which solution did I use previously and why did I switch?

I have used IBM MQ software, but it was not applicable to this application.

Which other solutions did I evaluate?

I have evaluated and researched Axon, RabbitMQ, Kafka, and IBM MQ.

**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More VMware RabbitMQ reviews from users
...who work at a University
...who compared it with ActiveMQ
Add a Comment
1 Comment

author avatarPascal Sesques


I am a real user too and I would say that it depends really on the context. You can consider two generation of brokers, old ones are pure brokers (RabbitMQ, ActiveMQ, ZeroMQ etc.) and new ones are stream oriented (Kafka, Artemis, etc.). The performance difference is huge, around 4000 msg/s for old brokers, around 60,000 msg/s for stream based.

we used RabbitMQ for years and we are moving right now for many reasons:
- RabbitMQ is one of the leading implementation of the AMQP protocol. Therefore, it implements a broker architecture, meaning that messages are queued on a central node before being sent to clients. This approach makes RabbitMQ very easy to use and deploy, because advanced scenarios like routing, load balancing or persistent message queuing are supported in just a few lines of code. However, it also makes it less scalable and “slower” because the central node adds latency and message envelopes are quite big.
- Nevertheless, Using standard AMQP 0.9.1, the only way to guarantee that a message isn't lost is by using transactions -- make the channel transactional, publish the message, commit. In this case, transactions are unnecessarily heavyweight and decrease throughput by a factor of 250. To remedy this, you need to implement confirmation mechanism that challenge a lot the easiness of implementation
- Replication on RabbitMQ 3.6 (the last version supporting AMQP 0.9,1) makes RabbitMQ having deadlocks between nodes and created a lot of issues in production in our systems
- Last, Erlang is a black box and many times RabbitMQ crashes with Erlang errors that were a shame to make us able to diagnose quickly and efficiently.

So my recommendation, don't use RabbitMQ on a transactional path, it remains good for back-office messages as long as you can implement your own transactions in an optimistic way (with retry and message duplication detection on application side)

In my context, we are moving to Kafka that shows performance, scalability and stability.