ActiveMQ Reviews

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.

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.

• Price point and licensing are the most valuable features relative to our previous MQ solution (Websphere MQ).
• Apache provides Docker images on the public registry for multiple versions of ActiveMQ. The value of the Apache-provided Docker image is that it spares developers from having to manually install ActiveMQ software. Using Docker, I can get a working ActiveMQ server up and running in minutes with zero knowledge of how the software is installed or what configuration files need to be tweaked, etc. Also, I can spin up an ActiveMQ farm of Docker containers within minutes if I want to test things like clustering, HA, etc. For something like concept testing or R&D, this is a fantastic way to save time and money.
• Multi-protocol support: http://activemq.apache.org/protocols.html. As we began to explore integrating IoT solutions, ActiveMQ’s support of the MQTT protocol was very convenient!

This product enabled development teams at my previous organization to R&D much quicker with JMS based applications, which basically comprised the entire middleware layer of the organization. Previously, we would get stuck waiting for license procurement for the IBM solution, which wasted project time and budget.

Apache ActiveMQ needs some improvement playing with multi-platform message clients. It already plays really well with Java clients since it’s a JMS implementation, but it needs some improvement supporting clients written in other languages (like C#).

I have been using the solution for 18 months.

We have not encountered any stability issues.

We have not encountered any scalability issues.

For an open source solution, support options are actually very robust: http://activemq.apache.org/support.html

We previously used WebSphere MQ and switched mainly due to licensing costs.

For us, initial setup was VERY easy since we were using the Apache-provided Docker image for ActiveMQ, which alleviates a lot of the traditional pains involved with installing new software.

This solution is awesome from both perspectives.

Before choosing this product, we did not evaluate other options.

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

The database and message queuing are valuable features. It is useful for apps that have a lot of messages as well.

Thanks to ActiveMQ, we have managed to set up an IoT application.

There is need for more protocols and maybe they should provide documentation on the internet as well.

During my summer internship, I developed a IoT application (a proof of concept). We had some Texas Instruments CC2650 sensors emitting to MQTT. For the first time, we wanted them to AMQP protocol with RabbitMQ, but the MQQT QoS 2 on RabbitMQ was a big problem. Thus, we switched to ActiveMQ. Unfortunately, we had to stay in MQTT, as ActiveMQ can’t translate protocols like RabbitMQ.

In the end, we used the ActiveMQ broker to get the messages from our sensors (using the Java Library by Hiram Chirino, mqtt-client), then we parsed the messages from the sensors and stored them in Apache Hbase. With all of this data, we made some statistics, graphs and various other useful stuff for the industrials.

About the documentation, it is more about the ActiveMQ advanced concepts such as using the KahaDB etc. For the protocols, maybe a translator is needed for example integration of AMQP to MQTT or XMPP to CoAP.

I have used this solution during a summer internship last summer.

We have not yet encountered any stability issues.

We have not yet encountered any scalability issues. Currently, we are receiving 1000 messages per second (on an average).

We have not used the technical support.

Previously, we were using RabbitMQ, but it didn’t support MQTT QoS 2.

It is a good, free and safe product.

We have tried Apache Apollo and RabbitMQ.

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.

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.

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.

The valuable features are:

• Message queues
• Camel routes
• High availability
• Serialization of batch jobs
• Consumer/worker throttling
• Message durability

We use ActiveMQ primarily to deliver work to backend worker services that run tasks with extremely variable run times.

I supported and used ActiveMQ from 2010-2016.

We ran into various stability problems with our implementations over the years. We also ran into a few problems related to bugs.

One of the bugs was a memory leak from the KahaDB log files. As uptime accumulated, it eventually triggered one of the artificial limitations on the disk space used by KahaDB.

There have been no issues with scalability, but we had a pretty low message throughput.

The installation was pretty straightforward. It was also easy setting up HA using an NFS share for hosting the KahaDB.

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.