ActiveMQ Reviews

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.

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.

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 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.

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.

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.

Most architecture nowadays requires too much performance. We can use products like ActiveMQ to improve our architecture.

I implemented a micro-services based architecture and did some of the communication via queues. I used actors with the Akka framework, and not only threads in Java.

The most important feature is that it's best for JVM-related languages and JMS integration.

The product is really straightforward. All the operations that you use are pretty simple and worked fine.

The deal is to write the correct logic.