ActiveMQ Reviews

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

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.

Most valuable to us are fast asynchronous message queuing with message-level acknowledging and message persistency.

ActiveMQ operates as the message bus across single-purpose components. Thanks to ActiveMQ, the system is able to scale its heavy computing components during traffic peaks.

I would like to see improvement in the clustering brokers. Configuring ActiveMQ brokers for working in a cluster is difficult and has many constraints. Also, the configuration files are not intuitive.

We have been using ActiveMQ for about 6 years.

We have not encountered any stability issues.

The only issue we had concerned the practical limit of 2000 messages per broker, per second. The next step, which is multiplying brokers, worked well though.

I have not used technical support so far.

Initial setup is quite complex when done for a high performance system. The configuration files are not intuitive.