ActiveMQ Reviews

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.

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.