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.

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.