We configure the monitoring and alerting for the RabbitMQ setup. We transfer the message to the designated queue if there are any errors or similar issues. We use a Spring Boot application and microservices for this purpose, making it easy to route the message.

If you want to use this solution, you first need to understand the concept of exchange queues. Certain clusters require specific knowledge. The configuration may vary depending on the application type. For instance, the configuration was relatively straightforward in our case with microservices. We only needed to provide authentication and the correct URL. If it ran on a cloud environment, we would provide the instance, username, and password, and the configuration would be handled automatically. It would depend on the language and the specific type of microservice or application for more advanced customization, such as writing code.

The solution is easy to use, configure, and install.

Overall, I rate the solution an eight or nine out of ten.

If you are looking for a queuing system for your application that guarantees insured delivery and ensures single delivery without duplicates, RabbitMQ is the right solution as it provides all these capabilities with ease of use.

With RabbitMQ, your application doesn't need to worry about receiving duplicate messages as the solution handles that internally, ensuring that each message goes through a single process for one delivery.

I highly recommend the solution and would rate it an eight out of ten.

I am using the latest version of the solution. I'm not sure of the version number. 

I've used this on multiple projects, and it has proven to be quite useful.

I'd rate the solution nine out of ten. It is a very good tool. 

People wanting to use the solution must learn how to configure and deploy it. If the documents are pretty clear, they will be easy to use. Overall, I rate the solution an eight out of ten.

I rate VMware RabbitMQ an eight out of ten. You should know how to configure and deploy it on the servers. If they provide good documentation, it will be easier to use.

You should use the solution if you want to store your details in the queue and start taking inputs from the queue. I rate it a nine out of ten. 

The RabbitMQ documentation is pretty good. I'd only suggest making sure to read through it for the implementation language of your choice first.

This is a great product. It is lightweight, supports cloud native applications, is easy to implement, is easily manageable, and has excellent support. I would say, just go for it!

Check the scaling issues. If scale is not an issue and you're just looking for a stable messaging queue, I would highly suggest it.

If scale is an issue, I would suggest using Apache Kafka.

My advice would be to have the messaging topology mapped out before you deploy to make the process from installation to a functioning solution more efficient. If you start looking at the topology from the revenue perspective, it usually ends up with more iterations to implement the correct topology, whereas if you start off mapping and then install, it's a more efficient way to go about it. 

I rate this solution an eight out of 10. 

I'm only really using the solution for the purposes of research. I've just installed and am working on the latest version. My interest in the solution is purely academic, so I can't speak to how it would function within an organization.

I'd definitely recommend the solution, especially over HTTP in the Nico services platform. I've done my research and have discovered it's two times faster and more commonly used. It's also really easy to use on the Nico services platform because all of the components are in the cloud.

I'd rate the solution eight out of ten.

By all means, try to reduce the amount of up-front configuration of RabbitMQ as much as possible.

At this point, we can spin up a very generic VM with RabbitMQ on it and get it in use immediately. However, that was not the case at the beginning.

RabbitMQ is very flexible, which is good and bad. Once the flexibility is understood, it’s great. Before that, you may be in for a little bit of head-scratching.

My advice for anybody who is implementing this product is to learn the concept of message queuing and study the AMQP 0-9-1 protocol. If you study this then you won't have any problem learning the system and working with it.

In summary, this is a good product that I will continue to use, and I recommend it.

I would rate this solution a seven out of ten.

For Node.js development, use amqplib. It’s a really good library for RabbitMQ.

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

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'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.

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.

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.

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

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.

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

Start it in Docker and use Java Spring Boot or Node.JS with amqplib to connect to it. It has transformed how I think data should flow in an organization.

It is a really good solution if you require queuing with the competing consumer and multicast routing out of the box. It’s a bit too elaborate if you need just simple message queuing.

I would advise potential customers to make sure it works with your architecture, scale plan, and load. There are other alternatives.

Do many stress tests.

This product is fantastic. Before you use it, make sure you analyze your real needs. In the world of message brokers, there is no single solution. Today, you have solutions that are specialized for specific use cases.

For instance, you have the NATS solution which is another great message broker tool. It is focused on handling a tremendous number of topics and messages per second and it consumes few resources.

However, it’s not as resilient as Kafka. Kafka can replay all the messages received from a date range. However, this one can handle fewer topics.

NATS is written in Golang. Golang is the Go programming language, which I love.

I would recommend this product. It is great and resolves a lot of problems.

Keep in mind that the queue structure and the consumer configuration need to keep up with the queuing speed. I would suggest researching other options if you need bulk data publish/subscribe in persistent data storage, e.g., Apache Kafka.

I've had the most success using NServiceBus over MassTransit. Look there for .NET Devs.

My advice for anybody who is implementing this product is to establish your users and exchanges properly.

In general, I'm quite comfortable with RabbitMQ. It satisfies my requirements and the main complaint I have is about the security.

I would rate this solution a seven out of ten.

I would give the following advice prepare a demo, with the vendor and check if it really applies to their needs. I would rate VMware RabbitMQ a nine out of ten.

Read the documentation and follow best practices. Make sure Erlang is up to date!

I would recommend it, but I think there should be a proof of concept for the developer team to get their hands around it and have full control of it before they go into production.

I would rate RabbitMQ a seven out of ten. 

In the next release, I would like for them to improve the UI.

I would advise potential customers to use something to wrap their interaction, like Spring for Java.

It gives product support with your technology.