VMware RabbitMQ Reviews

Guaranteed message delivery, queuing, and low latency delivery.

This allowed us to create a resilient network and independently scale various parts of the system dynamically as the business needs changed.

The biggest area we struggled with was operations troubleshooting. We were running a pretty big cluster and ended up with some random cluster failures that were difficult to troubleshoot. A good portion of these were self inflicted but occasionally the distributed database would end up corrupted.

I have been using RabbitMQ for six years, from prototype to production.

We had a bit of an issue with stability. The usual initial cause would be a hiccup in IOPS in EC2 but then this would cascade into more instability in our main clusters.

For the most part the product was very scalable. The only times we would have problems were usually related to Amazon hiccups that would cause the cluster to slow down.

We did not use their technical support much.

We evaluated a variety of message products and found that for the feature set RabbitMQ was the best.

Initial setup was relatively simple and then we were able to grow into the product by using more of the features.

We used the open source implementation and did not need to pay for support.

We looked at ZeroMQ, Kafka and Redis.

You really need to have or train Erlang expertise. The Erlang tools will become the best way to troubleshoot misbehaving clusters.

Legacy queuing systems have been replaced by RabbitMQ. The performance has been increased to a great extent.

The message routing is the most valuable feature. It is effective and flexible.

The debugging capabilities and testing flexibilities need to be improved.

The stability was fine.

There were no scalability issues as such. The scalability was fine.

I would give technical support a rating of 5/10.

Initially, we were using different queuing technologies. Due to the message routing feature and flexibility that RabbitMQ provided, we made the switch to this tool.

The setup was easy enough, once we had done proper research before the implementation.

The pricing is okay.

This product needs to be understood completely before implementing it. One should not be mistaken that it will replace the whole messaging system as such.

We primarily use the solution for consumers and publishers. It's for messaging and consumer publishing. That's it.

The solution is simple to use.

It's great for messaging and consumer publishing.

Companies can scale the solution, so long as they have server room.

The stability is good.

The user interface could be improved. We have an interface that shows the consumption rate, the number of consumers, their occupation rate. We should have a column in that interface that shows the estimated time until, at the current rate of consumption, the number of messages is to be consumed from a specific queue. That would be great. I wanted to read, however, as it is right now, JavaScript would have loaded the browser too much. Basically, I'd just like to see the consumption rate in each queue without too much fuss.

The solution could use some plugins that could be integrated into the server installation. We had a plugin that we used to delay something that from one version to the other was integrated into the server setup. Maybe it was more of an extension. However, more plugins could be also be integrated into newer versions of Rabbit.

I've used the solution since 2013 or 2014. It's been about eight years at this point. 

The solution is usually stable. We have problems with space on the Rabbit servers. When they are full, we might lose everything. That's a big no-no. This is a problem for Kafka as well, however, we have higher thresholds in that area. Rabbit is the poor brother to Kafka, so it receives less space. That's why, sometimes, in some departments, this problem occurs.

The solution can scale, however, we use a lot of space for Kafka. We have clusters through the servers, and there may be more for each department. If some needs appear, we can increase the number of servers in a cluster to better manage messages. As long as your company can increase the number of servers, it can scale. 

We have about 100 departments that use this solution in some way.

In our case, we have in our department five people and we have two clusters with Rabbit for two different directions. For us, it's enough. We do not plan to increase usage.

I've never directly contacted technical support. We use recommendations on the site, which is very good. I appreciate the recommendations, however, I'm not sure about the maintenance of the documentation from one version of Rabbit to the other. The older versions of the documentation might be less accurate.

Other departments might use, for example, Kafka, however, I'm unsure as I have no visibility on them.

I was there when the solution was initially implemented and, from what I recall, it took half a year. 

It was completely new. No one knew anything about it. However, we knew that we had to do something to improve the communication between departments. It was a good solution. That said, it took a long time before everyone understood how it works.

We had a few dedicated people who liked the idea of Rabbit and implemented it. It took a while for the rest of the company to get behind them and learn how to do it.

There are one or two people at any given time available to handle any type of maintenance responsibilities.

We handled the implementation process ourselves. 

We're using a few different versions. It depends on the department. Some departments have the latest, some don't, some use a very old version. I'm using 3.8. We do have plans to make an upgrade. 

It was a few years ago now when I learned this process of separating publishers versus consumers in terms of messages and communicating between departments. This was the biggest game changer for myself. I'd advise new users study that aspect and understand it.

I'd rate the solution at an eight out of ten. It's a very good tool and we use it all the time.

We use the solution on our SaaS platform to speedup and simplify customer access across services.

Some of the most valuable features are “publish and subscribe”, fanout queueing, and scalability.

We have a number of different use cases in our scenario. A key one is “publish and subscribe”. We have spent the last year breaking up a large monolithic application into microservices and each microservice has to subscribe to different events for the purpose of CQRS and other kinds of updates. RabbitMQ is perfect for “publish and subscribe”. It does an awesome job at fanout, perfect for CQRS, messages are delivered to all subscribers with almost no additional latency.

RabbitMQ provides the ability to scale queues in a very simple and elegant way. If it had a “failure queue” with robust delivery and recovery built-in with the same power, that would be great. We use a completely different queuing system for failures. So there is a little more effort to take messages in a failure queue, analyze them, figure out what went wrong and then restart them in Rabbit. It is doable, and we do it, but if we had a round trip solution in Rabbit, that would be awesome.

For me, having a robust failure queue, is high on the list of improvements needed in the near future. This is an important update needed because right now we are using Doctrine for our failure queue. Doctrine does a great job.

I have been using the solution in the past year.

Rabbit is a very scalable solution. We could easily queue 50,000 messages in less than a minute. The first day we introduced Rabbit to replace another queueing system that we were using, there was disbelief on the part of the product team because the response was so fast. We need tens of thousands of messages queued in a short period of time, approximately one minute. For example, one user action could spawn 65,000 messages. We also need the ability to segregate different queues. This solution did a great job.

The installation is very simple and elegant, and we love the graphics. It lets us see exactly what is happening with the ability to start the queue, stop the queue, consume messages on the queue. This is a huge help.

We design, develop and deploy the solution ourselves.

We are also evaluating Apache Kafka. Our process is very disciplined. We look at the analytics, the abstraction, the architecture relative to our technical architecture, we ask ourselves questions about the use case, which is better for use A or B. Kafka is not as simple for “publish and subscribe”. You can do it, but not the best fit for us. However as a queueing system, Kafka is great. The records are stored on the queue in the order they are received, However, you can easily search by topic no matter how large the list. Important if you keep track of everything.

There are many different use cases for each technology, as well as many approaches. So have the architecture team graph and document every solution. Have a few training days to clarify the goal, the solution and the implementation. One of the things we do in our training is to actually create prototypes, the abstract model of our ideal state. This demonstrates exactly what we all need to do. Developers understand more quickly with a model. It flattens their learning curve and they are more productive more quickly.

I rate VMware RabbitMQ a ten out of ten.

Asynchronous messaging; supporting data integrations between multiple applications on behalf of our many customers. RabbitMQ allows us to elegantly fan-out data to a variable number of subscribers, with almost zero effort.

We have been able to set up a messaging system that facilitates data integration between the software modules that we sell.

RabbitMQ allowed us to do this quickly so that we could focus on the business requirements, rather than divert our efforts to message broker implementations.

Once the architecture was proven, we were able to return to the RabbitMQ message layer in order to implement an HA cluster with a minimum of problems encountered.

Our business now has a fit-for-purpose information hub that we can apply across our systems. As the customer-base grows, we know that the hub can grow with it.

RabbitMQ is a solid, widely-used messaging system with a low cost-of-ownership. It is open, but with commercial support potentially available from Pivotal if required. (We have never needed it.) There is also a strong online user community.

One crucial feature was guaranteed messaging. We needed a solution that we could trust to not lose data.

Its built-in clustering capability allowed us to configure it as a highly available message broker, so that we can have confidence in the resilience of our architecture.

It can be scaled as well, although we have not tested this.

After almost two years' usage in our production environment, I am impressed by how stable the platform is - even when running on Windows Server 2012. Sure, we have had to tweak our set-up here and there as we have learned a few operational lessons along the way but overall it is very good.

RabbitMQ is clearly better supported on Linux than it is on Windows. There are idiosyncrasies in the Windows version that are not there on Linux.

The documentation for the Windows version is also less plentiful and less accurate.

The online community clearly provides better Linux support, but this naturally follows from the smaller Windows installed base.

There are also some potential concerns about how we maintain high-availability whilst also scaling out.

We have had no stability issues.

We have not used the scalability features yet.

We have not used technical support.

No previous solution was used.

The initial setup was straightforward. The online documentation was adequate and there is minimal initial configuration required to get up and running.

After that, it is simply a matter of experimentation with the various features and learning as you go.

This is an open source solution.

We looked at MSMQ, NServiceBus, Azure Service Bus, and Apache Kafka.

I would recommend that anyone who intends to deploy RabbitMQ on Windows should first consider whether a Linux implementation is a viable option for their situation.

The most valuable feature is it’s robustness. Message queues need to be extremely reliable as they are the glue between system components.

Also, the speed is important and its good scaling capabilities.

It allows developers to focus on application functionality without having to re-invent interprocess communication, which is difficult.

I also allows us to develop smaller, more efficient, and less complex subcomponents of a larger application.

I would like to see better documentation on how to set up complex webs of RabbitMQ servers — master/slave, multi-master, etc.

I have been using RabbitMQ for 7+ years.

We have not encountered any stability issues.

We have not encountered any scalability issues.

We were using IBM MQ, but it was too costly and not open source.

The initial setup was simple for my applications, but I have not used RabbitMQ on a complex project that would require clusters of servers.

My advice is to read the message boards and play with the API.

Message queue, because it is easy to use, reliable, not a big load.

We are using it to distribute pieces of some large jobs to multiple machines, which improves performance several times.

Improve the ability to handle the large message load.

People usually use RabbitMQ as the lightweight messenger, if they have a large message load people are inclined to use Kafka. But at the beginning stage of most projects, the data is small, people do not need to use a Kafka type of messenger, they are more likely to use RabbitMQ. If RabbitMQ can handle the large message load and support ordered delivery, with the project growing, data bigger, people can still use RabbitMQ and wouldn't need to find another tool to use like Kafka which is much more convenient.

Half a year.

Didn’t have issues.

Didn’t have issues.

Very good. 8/10.

Simple. We followed the tutorial about RabbitMQ with Python.

We are using it internally with a very small data load in the developing period, which is free right now.

Yes, I evaluated Kafka.

Kafka is more suitable to large amount events in order. RabbitMQ is more suitable to the related small amount of messages, which is my situation and I don’t care about the message order.

RabbitMQ is a very easy to use and reliable message broker. If the work has a relatively small message load, RabbitMQ is the most robust and reliable choice.

• Load balancing through queues
• Guaranteed messaging
• Configurable pre-fetch count
• Queue mirroring

RabbitMQ helped us build a database synchronization framework that allowed us to transfer our clients data to our cloud based data processing centers.

The web management tool.

I have used this solution since 2013.

We had several de-clustering problems.

We did not have any scalability problems.

I have never used support.

This is the first solution we implemented.

It was a very simple setup. We had some issues with the home folder being on a non-standard system drive (The location of the RMQ cookie was changed.)

The Community Edition works fine for us.

We evaluated several other solutions; the MQSeries and MSMQ.

Use it for implementations that require a queuing solution. It is easy to overuse it as a universal communication bus of the entire system.