Overall, I would rate the solution a six out of ten. I'd advise if your requirement is on a smaller scale, then go for it. If it's a big scale with more events and higher throughput, consider Apache Kafka instead.

For our use in microservices, I'd rate it a nine or a ten.

If you are working with a small application, and you can manage losing data, or at some point, losing connection, the solution is fine.

Overall, I would rate ActiveMQ a five out of ten.

The performance of ActiveMQ meets our needs adequately. We selected it as our messaging solution because we believed it was the best fit for our requirements, and we haven't encountered significant performance issues directly related to ActiveMQ itself. The challenges we faced were more related to issues like hosting environments, such as OpenShift, and hardware limitations. 

Overall, I would rate ActiveMQ as an eight out of ten.

• Try not to use the temp queue.
• Pay attention to message selectors and queue size.
• Pay attention to queue names as if you use a wrong queue name, AMQ won't report the error but it will create a new queue for you which is sometimes hard to investigate.

I would rate the product a nine out of ten. You need to scale the application to interact with other automation and robotic systems. Most people or many people recommended using ActiveMQ on small and medium-scale applications.

I give the solution a six out of ten. 

Our customers would use the solution in any model. We have to test with the on-premise deployments and run on an EC2 cloud.

We have about ten users in our organization.

We do not require any people for deployment or maintenance.

Whenever we need support we get it from the online community.

I do not recommend ActiveMQ over Apache Kafka partly because I don't know who provides support for the solution.

When our clients are looking for AMQ protocol support specifically ActiveMQ is our recommendation.

It depends on the use case, which is if you want to go for scaling and horizontal scaling, and the better, two-way scaling is actually required for that. ActiveMQ is very usable in that way, and it has the option of network process raising, which is a really good ActiveMQ feature. As well as the message toll replication.

These are some of the features that we can find in IBM MQ, but we can also find them in ActiveMQ. It depends on the use case. 

This is a good solution. It is low cost, high performance, and scalability. 

ActiveMQ is a good solution.

Because of these features, I would like to see added, such as data sharing and scalability, I would rate ActiveMQ an eight out of ten.

I would give this solution 10 out of 10.

It's a very easy-to-use product. Documentation is sufficient, and anyone with a bit of knowledge about technology, like Java, can quickly set it up and it could be up and running in minutes.

I fully recommend this product, but you need to have some expertise working with JMS and asynchronous tasks. You also need a correct strategy, or at least think about one.

For what and where it is used, depending on the project, it will be very good.

For example, if I need to use a web application that will have ability to have an embedded message queue, it can work perfectly.

But if I need to have solution for big data, it may not be the best, especially for large streaming data. It varies by use.

Vet other solutions before implementing anything. Run multiple tests, like multi- thread and flood it with messages, as well as large messages, and combinations of both. See how it behaves.

I rate the solution an eight out of ten.

I would rate the tool an eight out of ten.

I have also had experience with IBM MQ for the last 30 years. I am comparing between different products and messaging scenario expertise.

I work in consultancies with many clients who have many different versions.

All messaging whether it's ActiveMQ, Amazon MQ which is Active MQ, or it's IBM MQ, they are all very similar, they all have strengths and weaknesses.

We have clients from small to large enterprises.

I would recommend this solution but it depends on the requirements. For example, what kind of support does the vendor want? What kind of managed services do they want? It is important because you can run ActiveMQ on AWS to get a managed service. It always depends on what their clients are looking for.

I'm impressed, I think that ActiveMQ is great.

I would rate this solution a seven out of ten.

ActiveMQ is a great messaging system for synchronizing call and "fire and forget" types of calls. It can be integrated with Spring, Camel, and Struts.

If possible, use the Docker image that Apache foundation builds!

Make sure your queues and topics are correctly named as it can quickly become a mess.

Overall, it is a good product but lacks some documentation.

Check out RabbitMQ. Run it in a Docker container out of Kubernetes with a persistent volume. You could probably do that with ActiveMQ, but it would require working with KahaDB, or establishing some other backend database pod.

• One needs to understand how asynchronous messaging works and the idea behind it.
• Plan your production environment and security requirements early on. This includes clustering, encrypted client traffic and read/write/admin rights on queues and topics.
• All messages will have a unique message ID, but also consider generating and logging a unique ID per message in your sending application. This ID can be propagated as a JMS header to all receiving applications and logged, in order to facilitate traceability later on.

Make sure you need all the facilities that a message broker offers, as there are other lightweight solutions out there.

Use the right tool for the job. Evaluate your needs carefully. Ensure that you do adequate performance, load, and failure mode testing prior to introducing the solution to production.

If you are getting started, go with Kafka.