ActiveMQ Reviews

ActiveMQ inside AP is one of those powerful features because we generally use ActiveMQ for acting on incidents which do not involve any human interaction or personal activity. For example, you have to act on some response which is being received by another third-party system, and we totally have no idea when that response would be coming. In that case, you can set up an ActiveMQ, and whenever any message gets sent to that ActiveMQ it can react based on your configurations, and you can trigger some processes, calls, or signals.

ActiveMQ is beneficial in cases where we do not know when the response will come and when we do not know who is sending that response. We do not know the sender, sending time, or message type. In such cases, we can configure multiple MQs and configure actions for them. Depending on the message body, sender, type of message, and timing, it will react. This reduces human interactions and manpower efficiency efforts.

The best feature of ActiveMQ is the integration capability because it reads an XML structure which is understandable to every system we currently have. If any client or service is sending any response, we can translate it to JSON or XML at any time. ActiveMQ works on XML and has no limitations regarding system interactions. It can interact with any type of system and has no language dependency.

Inside AP, ActiveMQ's ability to support different messaging protocols is configurable. Inside AP, MQ supports specific protocols that are configurable from the platform body. The protocol must be chosen based on the request type. For example, if we have JSON, the protocol can be different, and if we have XML, the protocol can be different. It supports whatever is configured.

In my current organization, I'm only working with ActiveMQ. I previously worked with IBM WebSphere MQ.

The features of ActiveMQ and WebSphere MQ fundamentally do the same thing. From my experience, I prefer WebSphere MQ. Both are very sturdy solutions; there is no doubt. Both are sturdy and stable, and ActiveMQ demonstrates excellent stability.

ActiveMQ supports various messaging protocols including AMQP, MQTT, and OpenWire.

We have a digital ID platform that uses various services running on Kafka. There are two main endpoints where services interact with external services. These include an automatic biometric service (Avis) and a print service, among others. ActiveMQ is used to manage the flow of registration data and interact with these services.

ActiveMQ has facilitated efficient data flow management between our internal and external systems. It supports high throughput and low latency, enabling our operations to run smoothly. However, recent issues with stability have prompted us to explore alternative solutions for potentially better performance.

We often work on message transfer between sensors. An IoT device sends a message about a sensor failure to the database. Before inserting into the database, the failure message is sent to ActiveMQ, and that uses a Python script to insert it to the internal database.

The main function I find valuable in ActiveMQ is facilitating message transfer within the client's internal network. ActiveMQ handles the message transfer from the internal network to the cloud. Regarding multi-protocols, we use different approaches based on client capabilities. Some clients connect for real-time data transfer, using database queries for periodic updates every ten minutes. We collect data from multiple clients, ensuring we get real-time sensor values where possible and periodic updates for others. This flexibility is crucial as we aim to enhance inter-network communication and compare solutions for future improvements.

We used it for communication between microservices. For example, if service one makes an update and service two needs to be aware of it, and it doesn't need to be synchronous, it can handle that later as well. 

The feature of ActiveMQ which I feel is good is its ability to have DLP, the later queues. If something goes wrong with the platform, it retries. Even if it fails, it goes to DLP, and later we can rescan the same event for processing. 

The ability to store the failed events for some time is valuable.

I use it, not in production, just for some software tests.

It's kinda just for showcases. For example, if you wanna show a solution or concept in GoLang that needs a message broker, ActiveMQ is a quick solution to get one up and running. 

The main reason for the showcase is the Go application, in this example.

Since we use it outside of production, we mostly use the basic queueing concept of the tool. It's more about getting a queue up quickly for showcasing or trialing a bigger solution, not specifically for the features of ActiveMQ.

We like it because it's simple to start. You can run it in a Docker container; it is almost plug-and-play. 

The simplicity, that's the best quality of the product.

I would like the tool to improve compliance and stability. We will encounter issues while using the central applications. In the solution's future releases, I want to control and set limitations for databases. 

I have been using the tool for three years. 

ActiveMQ brings the most value to small applications because it will not cost you very much to complete.

There are two areas that the product should improve. One, the solution needs to be maintained manually and two, there are some stability issues.