Senior Director, Engineering at Tanla Solutions Ltd
Real User
Top 20
2024-08-01T06:05:10Z
Aug 1, 2024
Other tools besides RabbitMQ provide good TPS and HA. If RabbitMQ can match what its competitors provide, then we can probably give it a ten out of ten.
The product needs to focus on offering more use case documentation because browsing the internet to find it can be a process filled with struggles. It would be difficult to find some documentation that can let you know how to choose the right integrations for the product. The documentation should be improved by the solution.
Once in a while, we have downtimes associated with RabbitMQ. However, the long-term solution is to architect your solution for a commercially supported messaging broker.
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.
When we had outages, we had timeouts. Sometimes, the nodes would drop out of a cluster. Therefore, the applications would get timeouts. There is a newer version out that we're planning to upgrade to for some stability. It could also be caused by our design. The product must improve its reliability. It'd be nice if nodes could drop out and notify each other in a timely manner so that the applications wouldn't know if there was a problem.
Learn what your peers think about VMware Tanzu Data Solutions. Get advice and tips from experienced pros sharing their opinions. Updated: November 2024.
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.
Other tools besides RabbitMQ provide good TPS and HA. If RabbitMQ can match what its competitors provide, then we can probably give it a ten out of ten.
The product needs to focus on offering more use case documentation because browsing the internet to find it can be a process filled with struggles. It would be difficult to find some documentation that can let you know how to choose the right integrations for the product. The documentation should be improved by the solution.
Once in a while, we have downtimes associated with RabbitMQ. However, the long-term solution is to architect your solution for a commercially supported messaging broker.
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.
When we had outages, we had timeouts. Sometimes, the nodes would drop out of a cluster. Therefore, the applications would get timeouts. There is a newer version out that we're planning to upgrade to for some stability. It could also be caused by our design. The product must improve its reliability. It'd be nice if nodes could drop out and notify each other in a timely manner so that the applications wouldn't know if there was a problem.