ActiveMQ Reviews

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.

One of the most important features of ActiveMQ is the ability to set up a network of brokers, and the ability to forward the message to another broker in the network, where there is a demand for messages from a consumer. These brokers could span over WANs and geographies. The messages will get forwarded to the broker where the demand is, which is what makes this a distributed messaging system.

The 'Shared nothing' configuration, where each broker has its own DB instance, is very important. It ensures that every message is accounted for and persisted in the DB to be replayed in case of failure.

Load balancing is important when huge numbers of messages are coming in. The messages get distributed to all the brokers, which are connected. In case of failure of any one broker, the message automatically gets routed to other brokers, ensuring no loss of messages.

By default, the failover protocol uses a random algorithm to choose one of the underlying connectors. If the connection fails, the transport will pick another URI and try to make a connection. The network automatically passes messages to connected brokers that have interested consumers. The failover protocol ensures clients do not need to be manually restarted in the case of a broker failure. As soon as the broker becomes available again, the client will automatically reconnect.

We also appreciate the easy setup of persistent messages using a DB like Oracle.

The master-slave relationship between brokers needs some improvement.

In case of shared architecture between brokers (i.e., both brokers sharing same the DB instance), one becomes master and the others become slaves. In this situation, the master always consumes the message and the slave is always in a dormant condition. This makes load balancing impossible. Probably this can be improved upon.

Another area of improvement is the monitoring console, which is kind of rudimentary. There is no facility to trace the entire XML message and take corrective action, such as resending the message.

If these facilities are added, it will be very good.

I have been using ActiveMQ for 2 months.

We have not had any stability issues.

We have not tested scalability.

We considered switching from WebLogic JMS, since we faced many issues including message affinity and lost messages.

The initial setup was straightforward.

The pricing and license policies are pretty good.

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.

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.