ActiveMQ Reviews

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.

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.

Scalability is good as it has the concept of a "network of brokers", so there are no different queue names for distributed queues or physical queues.

The network of brokers scales by need but the queue name stays the same, hence the client does not need to worry about queue name change.

For example, if you use MQ from Oracle weblogic to implement messaging system with scalibility in mind, then you would implement one distributed queue on managed server and physical queues on each node, ideally the client connects to your distributed queue which has been configured to distribute messages to each physical queue by either round robin or weight policy etc.

In the above example, if you add new nodes then you have to add newly created physical queue to the distributed queue, or you have to inform the client what is the new physical queue name if your client choose to connect to the physical queue instead of distributed queue.

With the concept of the network of brokers, AMQ may add more brokers under load, but it always expose the same queue name to the client, so client won't notice the scale change and you don't need to config extra queues when it scales

It is cost effective and is a much cheaper solution compared to Weblogic or IBM MQ.

It has good performance in general use cases and is reliable.

It is easy to implement, especially in an MVP project for PoC.

It is easy to configure a composite queue for message forwarding.

We have had problems with the message selector as when the queue size reaches a certain level, the message selector does not have enough time to run and finish before the JMS reply timeout. In this case the client will not consume the JMS reply message even when the correlation ID matches.

Try not to use the hawt.io feature but use the AMQ console which is much better. If you have to use hawt.io , you may need to configure Jolokia, which is the JMX layer of hawt.io, to display queues properly if you have a lot of queues.

I have been using the solution for about four years now.

I have not experienced any unstable situations.

I have not encountered any scalability issues.

I have no experience with the technical support.

I have used Weblogic MQ and IBM MQ before, and I switched to AMQ because we wanted to have a cheaper, faster and easier solution for messages.

The initial setup was very straightforward. Just follow the manual and there will be no issues.

I have no experience in enterprise pricing and licensing.

I have evaluated Rabbit MQ, which is the fastest solution, but AMQ has more features and better support.

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

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

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.