ActiveMQ Reviews

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.

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.

ActiveMQ is the middleware to consume the payloads because some applications are incapable of consuming APIs and other such things.

Alternatively, they may want to send an offline message once the process is complete, and then put that message into ActiveMQ for the middleware application to consume.

We do not use this product extensively. It is primarily used as part of our application deployment and message structuring. 

We haven't used the majority of ActiveMQ features internally. As I previously stated, it is similar to middleware, middle messages, and pushing them.

We use ActiveMQ for message brokering in our architecture. It is a central hub where we publish codes like city codes and office IDs for our server application. Other applications subscribe to relevant topics on ActiveMQ to receive and consume these messages, ensuring they stay updated with the latest code information.

For reliable messaging, the most valuable feature of ActiveMQ for us is ensuring prompt message delivery. Losing messages could lead to critical issues, especially when different systems need to exchange time-sensitive information like financial records. 

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.