ActiveMQ Reviews

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.

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.

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.

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

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.

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.

The most valuable feature of this solution is the holding and forwarding.

From our perspective, it does not require improvement, because our use case is limited to pushing and consuming messages, and we will not be using the product extensively in terms of their life cycle or broadcasting, or message broadcasting, as a normal MQ would. 

That's why I am not sure because this is based on our use cases. Most of the features that we are looking for are present, and because we are not using any of the mirroring queues, destination options, or anything else, delivery policies, and so on. That is managing within the application itself. It is dependent on the pattern of use cases to use cases.

Because this is an open-source project, there is no support. We don't have any help or anything like that. 

This is usually us, otherwise, we have to search for it, who is the consumer, and search for who is supporting it. 

When it comes to new implementations, ActiveMQ is usually one of the applications and one of the ActiveMQs that we support out of the box. That requires the use cases that you support and are taking.

I am not sure if that capability exists or not but it i's more like scalability exists, but it's more like the partition siding.

It would be great if it is included as part of the solution, as Kafka is doing. Even though the use case of Kafka is different, If something like data extraction is possible, or if we can experiment with partition tolerance and other such things, that will be great.

In terms of the graphical user interface, it is providing whatever is required in our cases. I don't have a proper status to give it, because instead of the queue size, I need to visually show the queue depth and all that stuff, that statistics and queue data and all that stuff. All of these are features that can be included in this.

We are incorporating it into the application. ActiveMQ is one of the middleware applications we use.

We have been using ActiveMQ for approximately eight years now.

It is not the most recent. I believe we have taken one or two steps back.

ActiveMQ is a very stable solution.

ActiveMQ is scalable.

That capability is included in the product, but it is also limited to the use cases of our applications because we are using it as part of the middleware services, which will scale it when the application scales up.

The Mule versions we are currently using do not have that horizontal scalability. It is vertically scalable, which means that you can use it for that type of scalability, but it also supports horizontal scalability, which is very important in today's world.

People are primarily using the solution as part of a middleware application, there are many of our, major clients, which are internal applications that consume it, such as credit or credit systems, and so on. 

They intend to make extensive use of it as part of their message dissemination efforts.

The production engineer, application support technicians, application developer, and lead designer are the people who use it. This is the group of people who are actively participating or have the authority to know who is contracting with us.

ActiveMQ is a component of the product that is currently being developed.

Previously, we used IBM MQ, but it is now something that is recommended in the internal queuing mechanism for the middleware. That is why we are using this. Aside from that, we do not use ActiveMQ anywhere in the organization.

The initial setup is easy. 

It's not particularly difficult. Most things relating to Apache implementations and everything else are straightforward. That part is excellent with us.

It can take a maximum of 15 to 20 minutes to deploy.

The implementation is completed entirely in-house.

It is usually one or two guys from the production support, or from the development team. 

One or two developers are managing it because it is part of the solution, and production can handle it as part of the production support team. 

The middleware production support team, Mule is one of our middleware, and they can manage that.

There are no fees because it is open-source.

There are no fees to begin using it.

It depends on the use case, which is if you want to go for scaling and horizontal scaling, and the better, two-way scaling is actually required for that. ActiveMQ is very usable in that way, and it has the option of network process raising, which is a really good ActiveMQ feature. As well as the message toll replication.

These are some of the features that we can find in IBM MQ, but we can also find them in ActiveMQ. It depends on the use case. 

This is a good solution. It is low cost, high performance, and scalability. 

ActiveMQ is a good solution.

Because of these features, I would like to see added, such as data sharing and scalability, I would rate ActiveMQ an eight out of ten.

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.