Implementing a circuit breaker scenario using RabbitMQ is complicated. This complexity arises because manual intervention is required to manage worker details and handle operations based on worker IP addresses. The use of public and private ports, specifically HTTP 8082 and HTTPS 8092, introduces complexity. So, we had thought about moving away from RabbitMQ to Anypoint MQ because there is a complex scenario where we need to implement a circuit breaker. Using RabbitMQ is getting complicated, so we need to implement it manually. Anypoint MQ is well-optimized within the Anypoint platform itself. Anypoint MQ is a Mule-related broker, so it's very well optimized for the Anypoint platform itself. So, it will be easy if we are using Anypoint MQ; we can implement this circuit breaker scenario in a very easy way. But because using RabbitMQ, it is a bit complex, because we need to get the details of the worker and we need to catch, we are stopping the worker based on how many workers we are having by getting their IP addresses, and this stuff is getting pretty much complicated. Then, all this stuff will work when you are on HTTP's public port 8082. But in general, we won't use public ports. HTTP 8082. We generally use 8092, which is a private port over HTTPS configuration. This will help us in several ways: the security purposes of the organization and everything else. So, that's why it's getting a bit complicated to implement this scenario while using RabbitMQ. So we got to move to Anypoint MQ.
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.
Solutions Architect at a tech services company with 51-200 employees
Real User
Mar 9, 2023
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.
Learn what your peers think about VMware Tanzu Data Solutions. Get advice and tips from experienced pros sharing their opinions. Updated: December 2025.
Independent Technology Consultant - Financial Softwares at a tech services company with 51-200 employees
Real User
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.
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
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
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.
Senior Developer/Architect at a tech services company with 51-200 employees
Consultant
Apr 15, 2017
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.
VMware Tanzu is a robust platform tailored for data warehousing, complex analytics, BI applications, and predictive analytics. It excels in scalability, performance, and parallel processing, enhancing data handling efficiency. Users report significant productivity improvements and streamlined operations, making it ideal for comprehensive data solutions.
Implementing a circuit breaker scenario using RabbitMQ is complicated. This complexity arises because manual intervention is required to manage worker details and handle operations based on worker IP addresses. The use of public and private ports, specifically HTTP 8082 and HTTPS 8092, introduces complexity. So, we had thought about moving away from RabbitMQ to Anypoint MQ because there is a complex scenario where we need to implement a circuit breaker. Using RabbitMQ is getting complicated, so we need to implement it manually. Anypoint MQ is well-optimized within the Anypoint platform itself. Anypoint MQ is a Mule-related broker, so it's very well optimized for the Anypoint platform itself. So, it will be easy if we are using Anypoint MQ; we can implement this circuit breaker scenario in a very easy way. But because using RabbitMQ, it is a bit complex, because we need to get the details of the worker and we need to catch, we are stopping the worker based on how many workers we are having by getting their IP addresses, and this stuff is getting pretty much complicated. Then, all this stuff will work when you are on HTTP's public port 8082. But in general, we won't use public ports. HTTP 8082. We generally use 8092, which is a private port over HTTPS configuration. This will help us in several ways: the security purposes of the organization and everything else. So, that's why it's getting a bit complicated to implement this scenario while using RabbitMQ. So we got to move to Anypoint MQ.
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.