ActiveMQ Reviews

We use ActiveMQ for message brokering in our architecture. It is a central hub where we publish codes like city codes and office IDs for our server application. Other applications subscribe to relevant topics on ActiveMQ to receive and consume these messages, ensuring they stay updated with the latest code information.

For reliable messaging, the most valuable feature of ActiveMQ for us is ensuring prompt message delivery. Losing messages could lead to critical issues, especially when different systems need to exchange time-sensitive information like financial records. 

In terms of improvement, one potential area would be the complexity of the initial setup. It is not overly complex, but it could pose challenges for first-time users.

I have been working with ActiveMQ for two years.

ActiveMQ has been a stable tool for us, with no downtime or critical technical issues so far.

ActiveMQ's scalability meets our project needs well. Our application doesn't require rapid message delivery, so we haven't encountered scalability issues. The frequency of code updates isn't extremely high, so ActiveMQ effectively handles our messaging requirements without any significant challenges.

The technical support is quite good. I would rate it as a nine out of ten.

Positive

Setting up ActiveMQ initially was not overly difficult for us. However, as it was our first time using it, we faced some challenges during client installation. The setup itself wasn't problematic; rather, our lack of familiarity with the system caused some initial hiccups. Once we gained experience with the installation process, subsequent setups became much smoother.

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.

We use the solution to manage the event messages by controlling the flow rate, handling error resubmissions, and ensuring the controlled processing of events.

The solution provides the best support services. It prevents losing messages with reliable techniques. Also, we can set thresholds for messages using it.

The solution's dashboard needs improvement. Presently, we cannot see the actual count of the messages. Also, we encounter downtime issues while queuing messages for third-party systems. They need to improve this particular area.

We have been using the solution for the last six months.

The solution's stability needs improvement.

We have around 300 applications for the solution.

The solution's technical support is good. Although, it took longer to respond to some of the queries related to licensing and stability.

Positive

I used JMS before.

The solution is less expensive than JMS and Kafka.

I rate the solution an eight out of ten.

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.

I would like the tool to improve compliance and stability. We will encounter issues while using the central applications. In the solution's future releases, I want to control and set limitations for databases. 

I have been using the tool for three years. 

I haven't contacted the support till now since I have a second layer support for the solution. 

The tool's pricing is reasonable and competitive compared to other solutions. 

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.

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.

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.

We use this product to provide us with a real time solution. It has helped us find ways to:

• Message or pass data, aside from hitting and saving data in a database.
• Perform asynchronous messaging.
• Queue database messages so requests are serial, if needed.
• Scale the application by increasing worker nodes via topics and queue load balancing.

I appreciate many features including queue, topic, durable topic, and selectors. I also value a different support for different protocols such as MQTT and AMQP. It has full support for EIP, REST, Message Groups, UDP, and TCP.

I would like to see the following improvements:

• The way it stores data
• Needs to focus on a certain facet and be good at it, instead of handling support for most of the available message brokers.
• For example, AMQP is a different flavor of message broker. However, adding it to ActiveMQ dramatically shifts its methodology and design. It can handle it, but it will be bad at it. Either you create a new forked solution of AMQ with AMQP and align only with AMQP, or just don't do it.

There were stability issues. With a network of brokers, you get a lot of issues, especially if you have the publisher and consumer using the same channel or connection, on different topics and/or queues. It’s causing a lot of issues and weirdness.

Setting up a network of brokers is problematic. The best thing is to do master-slave with a cold backup.

It is open source, so you get a very good response from the community. I heard Fuse is good, but I never talked to them.

We used to deploy Apache Kafka, as it was best for big data.

The initial setup is easy, and you can embed the ActiveMQ on the test.

Depending on the problem, AMQ resolved nearly everything. However, it may not be suitable for complex issues.

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.

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.