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.

With ActiveMQ there should be more options. If you work with other technologies, for example, Java, there are many options. We can integrate the way we want ActiveMQ. We can create partitions and clusters, but AP is not providing such options currently. It only provides time, request response timing, the number of requests that need to be handled, and protocol types. The configuration needs to be broadened inside AP to perform in a better way.

Sometimes issues arise in production with ActiveMQ due to the number of requests. For example, if you have configured one thousand requests at a time and it receives one thousand and one messages at a time, it breaks. The configuration aspect is tricky. When configurations are proper, ActiveMQ almost has zero errors.

Inside AP, I have been working with ActiveMQ for approximately eight years, including changes in Swimlane and AP applications.

The deployment process with ActiveMQ is straightforward as it involves export and import functionality. AP automatically creates a JAR with an AWS export extension, which contains all objects and configurations. This export simply needs to be imported into other environments.

ActiveMQ's dual deployment capabilities have limitations because the AWS import functionality does not work on every environment. It requires proper setup, including the JAR and standalone components. Studio accessibility must be present, otherwise the AWS import will not function.

ActiveMQ is stable. If the server goes down, that is a different scenario, but apart from that, it is very stable. It can react to any number of requests when configured properly. There is no scenario where a message comes to ActiveMQ and it does not react. If the message is received properly and the configuration is correct, it will react accordingly.

The technical support for ActiveMQ is managed through a separate community. If support personnel are not available, tickets must be created, which can take between two to three days or up to weeks for resolution. It is suggested to have one person dedicated for support.

Positive

Before ActiveMQ, I had not worked with any other MQ services or MQ software in my experience.

The initial setup and first deployment of ActiveMQ is fairly simple. You just need to have the setup in your scripting which should be able to understand AWS import and have the standalone components.

Regarding clustering, I am not entirely sure about how it works with ActiveMQ. In our application, AP itself has two to four clusters, and in each cluster, the MQs are placed differently. The same MQ is not used in four clusters, as each cluster has its own MQ.

There are three important aspects of ActiveMQ: clustering, determining how many instances each cluster needs, and the configuration part.

On a scale of 1-10, I rate ActiveMQ an 8.

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.

Pricing is something to consider with ActiveMQ, though cloud pricing is not costly and depends upon the compute selection.

Focusing on AI is essential nowadays.

AI capabilities require improvement in future updates.

I have been using ActiveMQ for six years.

There is no installation as it is a platform as a service.

I simply create and use it without any additional steps.

I don't waste any time on deploying clients as there is no client for this. WebSphere MQ has a client, but ActiveMQ does not require one.

ActiveMQ demonstrates excellent stability and sturdiness.

ActiveMQ is scalable.

The technical support of Apache is very good.

As it is from Amazon, the support quality is excellent.

Positive

I used IBM MQ from the beginning of 2009 until 2018.

It has been almost six years since I had contact with IBM MQ.

We have not deployed ActiveMQ's flexible clustering as that requirement is not present for us.

We only use active-passive configuration.

On a scale of one to ten, I rate ActiveMQ a ten out of ten.

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 value ActiveMQ for its performance, throughput, and low latency, especially in handling large volumes of data and sequential management of topics. The system's efficient memory and processor footprint have been beneficial for our use cases, specifically in queuing and managing data flows between different endpoints.

We need to address the non-deterministic load issues. Sometimes, ActiveMQ either restarts automatically or goes into ActiveMQ mode, causing interruptions. We need to enhance stability and improve the deployment optimization to fully leverage the platform's capabilities.

We have been using ActiveMQ for at least three years now.

The stability of ActiveMQ has been rated seven out of ten due to occasional interruptions. These are particularly problematic because our operations cannot tolerate any interruptions, making it a critical issue to address.

We expect the number of users to grow significantly, and while ActiveMQ has been performing well so far, we need to ensure it can handle the scalability without any critical issues. We are considering professional support to aid in this.

Before ActiveMQ, we used RabbitMQ and Kafka's default queue management system. However, ActiveMQ was chosen for its superior performance and lower latency, which met our specific scenario requirements.

The initial setup of ActiveMQ was straightforward. We used an Ansible script, which based on the specified parameters, installed it efficiently. On a scale of one to ten, I would rate the setup ease as seven.

The deployment was handled by a team of up to four individuals, who also manage the maintenance of all critical infrastructure software, including ActiveMQ.

We evaluated RabbitMQ and Kafka's queue management system but chose ActiveMQ for its performance and low latency.

For high traffic volumes where management time on ActiveMQ is minimal and where the rate of flow from the provider is slower than from the consumer, ActiveMQ offers the highest performance based on our experience. It has been efficient for data flow control between two endpoints, despite occasional unexpected glitches.

I'd rate the solution eight out of ten.

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.

The UI. It's both a good thing and a bad thing. The UI is too simple. Sometimes you wanna see the messages coming to the queue, and you have to refresh the dashboard, the console of the product. Maybe the UI could be improved.

I've never used their customer portal. The Apache community is very large, so we usually find answers in the community forums.

We always get answers to our problems. So, my experience with the community support has been good.

There is a vibrant community, and it is one of the strongest points of this product. 

Positive

The company uses the complete solution, the vanilla Apache Kafka solution.

We have also used AMQ in production. In a large company, we're exposed to many solutions; it's likely you'll touch some of these at some point.

We often use solutions based on recommendations or what the enterprise architects decide. We don't typically do comparisons to decide on a specific tool.

For our use in microservices, I'd rate it a nine or a ten.

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.

The stability of ActiveMQ could be improved. Occasionally, the MQTT broker goes down, requiring a restart, so enhancing its stability would be beneficial. Also, the current monitoring tools could be more user-friendly and faster. I'm currently using the default ActiveMQ monitoring tool, which is quite basic. It would be great if it could provide more detailed insights into the queues, topics, broker status, publisher status, and consumer status.

I have been using ActiveMQ for less than one year.  

For scalability, I would rate ActiveMQ seven out of ten. It's suitable for small to medium-sized companies that need reliable data connectivity and real-time updates but may not be the best choice for large enterprises.

I haven't interacted with Apache's technical support directly, as I've found solutions to any issues online and haven't encountered significant problems with the service's availability or functionality.

Setting up ActiveMQ is relatively straightforward, especially using Docker. I haven't tried installing it from scratch on a server, but deploying with Docker makes it easy to move configurations to other servers. 

ActiveMQ has some competitors, like TIBCO EMS, JBoss Messaging Service, Apache Kafka, Solace, and RabbitMQ. In my opinion, ActiveMQ is suitable for our needs because we are not a big company. We prefer open-source solutions like ActiveMQ for now because they are less expensive or free.

Currently, we are using ActiveMQ because it meets our needs and is cost-effective. I'd rate ActiveMQ an eight out of ten for POC and small interconnectivity projects. It performs well in our context.

I would recommend ActiveMQ to others, especially for small projects or POCs. It's a good solution for messaging, but for enterprise-level projects requiring high stability and support, other enterprise products might be better.

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.

Everybody is now moving from ActiveMQ to Apache Kafka or RabbitMQ. Apache Kafka is much higher in terms of scalability and stability; it's way ahead.

So, there is room for improvement in terms of stability. 

I used ActiveMQ in a previous project. 

I would rate the stability a five out of ten because sometimes it gets stuck, and we have to restart it.  We often need to restart it.

In our organization, maybe close to 2,000 people used this solution.

The initial setup is easy.

Overall, I would rate the solution a six out of ten. I'd advise if your requirement is on a smaller scale, then go for it. If it's a big scale with more events and higher throughput, consider Apache Kafka instead.

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. 

In terms of improvement, one potential area would be the complexity of the initial setup. It is not overly complex, but it could pose challenges for first-time users.

I have been working with ActiveMQ for two years.

ActiveMQ has been a stable tool for us, with no downtime or critical technical issues so far.

ActiveMQ's scalability meets our project needs well. Our application doesn't require rapid message delivery, so we haven't encountered scalability issues. The frequency of code updates isn't extremely high, so ActiveMQ effectively handles our messaging requirements without any significant challenges.

The technical support is quite good. I would rate it as a nine out of ten.

Positive

Setting up ActiveMQ initially was not overly difficult for us. However, as it was our first time using it, we faced some challenges during client installation. The setup itself wasn't problematic; rather, our lack of familiarity with the system caused some initial hiccups. Once we gained experience with the installation process, subsequent setups became much smoother.

The performance of ActiveMQ meets our needs adequately. We selected it as our messaging solution because we believed it was the best fit for our requirements, and we haven't encountered significant performance issues directly related to ActiveMQ itself. The challenges we faced were more related to issues like hosting environments, such as OpenShift, and hardware limitations. 

Overall, I would rate ActiveMQ as an eight out of ten.

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. 

I haven't contacted the support till now since I have a second layer support for the solution. 

The tool's pricing is reasonable and competitive compared to other solutions. 

I would rate the product a nine out of ten. You need to scale the application to interact with other automation and robotic systems. Most people or many people recommended using ActiveMQ on small and medium-scale applications.

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.

We have been using ActiveMQ for quite a while.

There are stability issues with this solution. We lose connection at times. When the application is down, we have to manually patch our servers, maintain them, and restart them. This is a cumbersome manual process.

ActiveMQ is not automatically scalable. You have to provision a server in order to scale to different regions, deploying another messaging queue.

Being open source, you can create a ticket on GitHub, however, there is no guarantee that it will be resolved. 

ActiveMQ is easier to set up than Amazon SQS.

ActiveMQ is open source, so it is free to use.

If you are working with a small application, and you can manage losing data, or at some point, losing connection, the solution is fine.

Overall, I would rate ActiveMQ a five out of ten.

The primary use case of this solution is to send messages between applications.

In all messaging applications, typically, sending and receiving messages is the most important and critical feature that we see our customers use.

The solution can improve the other protocols to equal the AMQ protocol they offer.

I have been using the solution for a couple of years.

The solution is fairly stable. But we are using it in Development, not in production, so I'm probably not the best judge of stability in general.

We don't see the solution used as much as Apache Kafka by our customers, but it is scalable.

We are supporting almost all the messaging platforms for our connectors. So I have been using other messaging products as well.

The initial setup is straightforward and only takes a few minutes. We have experience so it doesn't take a whole lot of time.

The implementation was completed in-house.

Since we are using the open-source version of the solution we do see a return on investment.

We use the open-source version.

I give the solution a six out of ten. 

Our customers would use the solution in any model. We have to test with the on-premise deployments and run on an EC2 cloud.

We have about ten users in our organization.

We do not require any people for deployment or maintenance.

Whenever we need support we get it from the online community.

I do not recommend ActiveMQ over Apache Kafka partly because I don't know who provides support for the solution.

When our clients are looking for AMQ protocol support specifically ActiveMQ is our recommendation.