ActiveMQ Reviews

The primary use case of this solution is to send messages between applications.

In all messaging applications, typically, sending and receiving messages is the most important and critical feature that we see our customers use.

The solution can improve the other protocols to equal the AMQ protocol they offer.

I have been using the solution for a couple of years.

The solution is fairly stable. But we are using it in Development, not in production, so I'm probably not the best judge of stability in general.

We don't see the solution used as much as Apache Kafka by our customers, but it is scalable.

We are supporting almost all the messaging platforms for our connectors. So I have been using other messaging products as well.

The initial setup is straightforward and only takes a few minutes. We have experience so it doesn't take a whole lot of time.

The implementation was completed in-house.

Since we are using the open-source version of the solution we do see a return on investment.

We use the open-source version.

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.

We are using ActiveMQ in our customers' companies, so all of the integrations are there. We use this solution for microservices intercommunication.

ActiveMQ is very lightweight and quick.

For Kafka, we mainly use it for event sourcing. We have huge concurrent events. From the TPS point of view, it's like 100,000 transactions that need to be admitted from different devices and also from the different minor small systems. Those are best fit for Kafka. We have used it on the customer side, and we thought of giving a try to ActiveMQ, but we have to do a lot of performance tests and approval is required before we can use it for this scale. I think Kafka is best suited for the concurrent high volume of events.

If these capabilities can be incorporated into ActiveMQ, it would be good to not have to use a second product. As a Q technology, everything in ActiveMQ works perfectly. But if that aspect of Kafka can be integrated or be a sub-component of ActiveMQ, it would be really great for enterprise-wide users.

We have been using this solution for three years.

The product is very stable. We haven't had any issues so far.

It's absolutely scalable. We are using the broker technology.

We don't have any subscription because we use the open-source version. But there have been a few queries around it, like if there's any support group that can provide commercial support. We were not able to find any company in the region with the support and upgrade patching, etc.

Before using this solution, we worked with IBM MQ more than four years ago. We switched because the first issue was scalability. I'm not sure about the current version, but when our team was working on the older version, scalability was one bottleneck. Second, we had challenges with the upgrades. From version six to seven, it was a challenge.

Initial setup was very easy. We used the containerized version. It took less than 30 seconds or so to boot the containers.

We are using the open-source version, so we have not looked at any pricing.

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 am impressed with the tool’s latency. Also, the messages in ActiveMQ wait in a queue. The messages will start to move when the system reopens after getting stuck.

The tool needs to improve its installation part which is lengthy. The product is already working on that aspect so that the complete installation gets completed within a month.

I have been using the solution for a year.

I would rate the tool's stability a seven-point five out of ten. The tool is highly stable.

My company has more than 1000 users for the solution.

The tool’s installation is tricky for someone who is installing it for the first time or has little experience with it.

I would rate the tool an eight out of ten.

We use this solution for messaging.

For any messaging system, I think that messaging, in general, is fundamental to software development.

This solution could improve by providing better documentation. IBM MQ has 30 years of experience to build upon and has had 30 years to grow and improve, while ActiveMQ does not have the same kind of heritage that IBM MQ has. In comparison, I find that IBM documentation is better, but it has had a lot more investment behind it.

In the next release, I think that a roadmap would be interesting. If we look at ActiveMQ and the ActiveMQ Artemis which are parallel streams that might merge, but it's not clear on whether it will or when will it happen. That would be useful.

Also, it is not that clear who offers what implementations. ActiveMQ is available as a managed service in AWS, but it is not clear whenever Red Hat AMQ is camping base around Artemis. It helps in terms of selecting why someone would want to use ActiveMQ.

I have had experience with ActiveMQ, on and off, for approximately five years.

I have not used it heavily in a production environment, but at the moment, I don't have any issues to report. 

I am currently working with some clients to investigate some stability issues they are experiencing, but it could be the result of the way it was implemented.

In terms of performance, I have not any extensive performance tests as a comparison.

I have looked at other messaging providers, and I don't think that it's any worse than any other solution available. I think that it's reasonable.

There is a little bit of community support, but when you have 30 years of experience, it is not difficult to work out. With messaging, you pick up on new messaging products and you can fill in the gaps very quickly.

The initial setup is straightforward.

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.

The ability to send large messages at decent speeds.

It had no impact on the organization. We used it in a solution we built for somebody else.

Even though there is support from many open source communities, there is still weakness in ease-of-use and ease-of-configuration for more complex scenarios.

The speed is not the highest ranking, but it's well known by users. They chose ActiveMQ for other features, because they know there are other messaging solutions that can work faster, like RabbitMQ, which is not Java written, but rather Erlang.

I have been using ActiveMQ for one year.

There were no problems with stability.

There were no scalability issues up to the point when I was involved in the project.

I didn't use their technical support, just the classical StackOverflow support. That gave me enough information.

We didn't have a previous solution.

The installation was straightforward. The framework we used, Spring, facilitates this integration.

We evaluated RabbitMQ.

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

Most architecture nowadays requires too much performance. We can use products like ActiveMQ to improve our architecture.

I implemented a micro-services based architecture and did some of the communication via queues. I used actors with the Akka framework, and not only threads in Java.

The most important feature is that it's best for JVM-related languages and JMS integration.

The product is really straightforward. All the operations that you use are pretty simple and worked fine.

The deal is to write the correct logic.

Message Management: Better management of the messages. Perhaps persist them, or put in another queue with another life cycle.

To clarify, it needs some queues in memory with the same abstract logic that ActiveMQ provides. An interesting example could be the embedded Redis framework, or the Derby database for integration tests.

ActiveMQ does not persist the messages in the queue. So it would be fine if active has that feature, or some way to do it. So you can grab that message any time during the application lifecycle.

Apache Kafka has that feature.

The improvement could be the availability to persist the message in the
queue for any time along the app running.

Testing: I did not find a correct way to test the integration using Java, but rather only with manual testing.

We did not encounter any stability issues.

There were no scalability issues. With a good strategy, we can scale onto large systems using ActiveMQ.

I would give technical support a rating of 10/10. Despite the doubts that I encountered during the development, I could get the answer in the documentation.

The initial setup is very easy. You don't need to install anything. Just run the start command or put the URL in the browser.

I think the software is free.

We evaluated Apache Kafka and also RabbitMQ. The choice was about the better integration with JMS.

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.

Reliable message delivery and mirroring.

It does not scale out well. It ends up being very complex if you have a lot of mirror queues.

We did have scalability issues. It does not scale out well.

As with a lot of FOSS (Free and Open Source Software), it is what you pay for.

This is our first foray into the world of messages.

The terminology and configuration took some time to learn. In some ways, it does not do what you think it will do, so be careful.

We looked at RabbitMQ and AWS SQS.

If you are getting started, go with Kafka.

It’s a JMS broker, so the fact that it can allow for asynchronous communication is valuable.

The clustering for sure needs improvement. When we were using it, the only thing available was an active/passive relationship that had to be maintained via shared file storage. That model includes a single point of failure in that storage medium.

We didn’t encounter anything that wasn't a result of our own misguided uses.

We did have scalability issues.

It's open source.

We didn’t have a previous solution.

The initial setup was straightforward. Whatever you don’t know, you can find via Google pretty easily.

It’s open source, ergo free.

We didn’t seek alternatives. We were told to use this.

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.

• Virtual topics supporting easy scalability of topic consumers
• Simple, yet flexible configuration of dead letter strategies
• The master-slave group with shared storage cluster topology

Loose coupling of components by the use of messaging queues allows for completely separate component life cycles and ownership within the organization.

It also greatly contributes to application maintenance and managing incidents, since no component is synchronously coupled to the other.

These are important considerations in a micro-service environment such as ours.

The included admin web app is not sufficient and we ended up disabling it. Instead, we are instead using hawtio and Jolokia.

However, the audit logging in Jolokia is not detailed enough and we were forced to write our own audit filter.

Even with hawtio, some JMX operations are awkward. A better admin tool would be nice.

I have been using ActiveMQ for approximately two years.

We have not encountered any stability issues.

The documentation is very good. Since this is a widely used product, there are plenty of good examples of how to solve various tasks. We have not used any other technical support.

The strategic architecture in the organization required a more lightweight, yet mature, capable, reliable, and scalable open source alternative.

We looked at Redis and RabbitMQ.

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

It has improved message processing. It removes the tight coupling and asynchronous invocation.

• Sequential message processing.
• Message broadcasting: There could be a use case sending the same message to all consumers. So as a producer, I broadcast the message to a topic. Then, whichever consumers are subscribed to the topic can consume the same message.
• JMX console: Provides a UI to visualize a list of queues and topics on the broker. We can see any pending message for particular topic/queue. It displays how many consumers are connected to a topic/queue. We can send a message from the JMX console to a topic/queue without the need of a producer to distribute the message.

• Distributed message processing would be a nice addition.
• An older version of ActiveMQ only provided failover, without a message spread across multiple nodes/broker. As with clusters (three nodes/broker), if one of the nodes goes down, other nodes should take the message and process it. If a message is consumed by a client, there was only one way to get the same message again.

We did not encounter many stability issues.

We did not encounter many scalability issues.

It’s open source, so we can’t expect more tech support. But the documentation has helped a lot.

We used JMS embedded in an application. Because of scalability issues, the JMS console, and isolation, we switched to ActiveMQ.

The setup was straightforward. Just download the extract and begin the startup script. That’s it.

I use open source with standard Apache licensing.

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.