The solution is a fine product. However, to make it perfect, in some cases, there might be a need to traverse the queue. RabbitMQ currently lacks the capability for archiving the queue, which essentially turns it into a log. For such requirements, you may need to explore other options like Kafka or custom drivers that allow traversing the entire queue. In RabbitMQ, while you can traverse the entire queue, you need to devise a workaround to handle the messages. For example, you can read a message from one queue, publish it to another queue or keep it in some other way to retain the desired entries, and then stop at that point. Additionally, the need for support may vary depending on the usage and potential heavy loads on the system. The support feature could benefit from some improvement in terms of accessibility and responsiveness. I don't encounter significant challenges or areas that require improvement while using the solution. Everything works smoothly, and I find it well thought out. It's got excellent compliance with MQP 9.0. Overall, I have had a positive experience with the solution.
The availability could be better. When something crashes, a queue gets deleted, and my data is lost. They need to improve this so that we don't lose data during issues like crashes. We'd like to understand how many queues are running on RabbitMQ. I'm not sure how to get these details and how to verify the information. We need other protocols.
Independent Technology Consultant - Financial Softwares at a tech services company with 51-200 employees
Real User
Top 5
2022-01-30T06:33:58Z
Jan 30, 2022
There are some security concerns that have been raised with this product. The configuration works with a config file, where all of the controls, including that of the administrator and user access, are stored there. The security isn't very stringent or very elaborate.
Assistant Student at a retailer with 5,001-10,000 employees
Real User
2021-12-27T19:08:00Z
Dec 27, 2021
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.
Sr Technical Consultant at a tech services company with 1,001-5,000 employees
Real User
2021-06-26T13:21:21Z
Jun 26, 2021
One of the issues is that as soon as you go outside of a switch or not in IP address range, the clustering no longer has all the wonderful features so clustering outside of network boundaries is a problem. I'd like to see stream processing as an additional feature. Kafka has a streaming API and I'd like Rabbit to have that too.
CTO, CIO, Chief Architect at a tech services company with 11-50 employees
Real User
2021-01-21T19:16:00Z
Jan 21, 2021
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 was struggling with installing a few things. It would be good if was somewhat similar to RedHat. There should be more documentation regarding installation troubleshooting. It's pretty straightforward, the setup, but it would be useful to know what to do if you do face certain challenges. Right now, without more in-depth documentation, it's unclear.
* Difficult to integrate with automated test and CICD * Moving beyond basic configurations can be challenging * Not clear how to implement durable subscriber connections * Not clear how a Rabbit service restart allows subscriber auto re-connect * Service cluster failover depends on shared disk infrastructure.
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.
RabbitMQ is the most popular open source message broker, with more than 35,000 production deployments world-wide. RabbitMQ is lightweight and easy to deploy on premises and in the cloud and runs on all major operating systems. It supports most developer platforms, multiple messaging protocols and can be deployed in distributed and federated configurations to meet high-scale, high-availability requirements.
We needed to configure additional plugins. While it was relatively easy to do this on-premises, it became more challenging in the cloud.
VMware RabbitMQ needs to create a new queue system.
VMware RabbitMQ's configuration process could be easier to understand.
The solution is a fine product. However, to make it perfect, in some cases, there might be a need to traverse the queue. RabbitMQ currently lacks the capability for archiving the queue, which essentially turns it into a log. For such requirements, you may need to explore other options like Kafka or custom drivers that allow traversing the entire queue. In RabbitMQ, while you can traverse the entire queue, you need to devise a workaround to handle the messages. For example, you can read a message from one queue, publish it to another queue or keep it in some other way to retain the desired entries, and then stop at that point. Additionally, the need for support may vary depending on the usage and potential heavy loads on the system. The support feature could benefit from some improvement in terms of accessibility and responsiveness. I don't encounter significant challenges or areas that require improvement while using the solution. Everything works smoothly, and I find it well thought out. It's got excellent compliance with MQP 9.0. Overall, I have had a positive experience with the solution.
The availability could be better. When something crashes, a queue gets deleted, and my data is lost. They need to improve this so that we don't lose data during issues like crashes. We'd like to understand how many queues are running on RabbitMQ. I'm not sure how to get these details and how to verify the information. We need other protocols.
I would like to see the performance of the administration portal improved and additional messaging protocols.
There are some security concerns that have been raised with this product. The configuration works with a config file, where all of the controls, including that of the administrator and user access, are stored there. The security isn't very stringent or very elaborate.
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.
One of the issues is that as soon as you go outside of a switch or not in IP address range, the clustering no longer has all the wonderful features so clustering outside of network boundaries is a problem. I'd like to see stream processing as an additional feature. Kafka has a streaming API and I'd like Rabbit to have that too.
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.
When you have complex tasks, RabbitMQ is hard to use. There are several things that you have to do manually, so there should be better tools for that.
Their implementation is quite tricky. It's not that easy to implement RabbitMQ as a cluster. It would be great if they could improve that.
I was struggling with installing a few things. It would be good if was somewhat similar to RedHat. There should be more documentation regarding installation troubleshooting. It's pretty straightforward, the setup, but it would be useful to know what to do if you do face certain challenges. Right now, without more in-depth documentation, it's unclear.
* Difficult to integrate with automated test and CICD * Moving beyond basic configurations can be challenging * Not clear how to implement durable subscriber connections * Not clear how a Rabbit service restart allows subscriber auto re-connect * Service cluster failover depends on shared disk infrastructure.
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.