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.
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.
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.
Lead Data Engineer at a energy/utilities company with 51-200 employees
Real User
Top 20
May 2, 2024
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. For additional functionality, I suggest making it easier to install and monitor the queues, topics, broker status, publisher status, and consumer status. Improved monitoring tools would help avoid needing to manually access the server for monitoring purposes.
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.
Senior Software Engineer at a retailer with 10,001+ employees
Real User
Aug 30, 2023
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.
Technology Lead at a tech services company with 10,001+ employees
MSP
Jun 22, 2023
The solution's dashboard needs improvement. Presently, we cannot see the actual count of the messages. Also, we encounter downtime issues while queuing messages for third-party systems. They need to improve this particular area.
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.
The tool needs to improve its installation part which is lengthy. The product is already working on that aspect so that the complete installation gets completed within a month.
Lead Architect at a financial services firm with 1,001-5,000 employees
Real User
Sep 16, 2022
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.
For Kafka, we mainly use it for event sourcing. We have huge concurrent events. From the TPS point of view, it's like 100,000 transactions that need to be admitted from different devices and also from the different minor small systems. Those are best fit for Kafka. We have used it on the customer side, and we thought of giving a try to ActiveMQ, but we have to do a lot of performance tests and approval is required before we can use it for this scale. I think Kafka is best suited for the concurrent high volume of events. If these capabilities can be incorporated into ActiveMQ, it would be good to not have to use a second product. As a Q technology, everything in ActiveMQ works perfectly. But if that aspect of Kafka can be integrated or be a sub-component of ActiveMQ, it would be really great for enterprise-wide users.
Solutions Architect at a computer software company with 1,001-5,000 employees
Real User
Feb 2, 2020
This solution could improve by providing better documentation. IBM MQ has 30 years of experience to build upon and has had 30 years to grow and improve, while ActiveMQ does not have the same kind of heritage that IBM MQ has. In comparison, I find that IBM documentation is better, but it has had a lot more investment behind it. In the next release, I think that a roadmap would be interesting. If we look at ActiveMQ and the ActiveMQ Artemis which are parallel streams that might merge, but it's not clear on whether it will or when will it happen. That would be useful. Also, it is not that clear who offers what implementations. ActiveMQ is available as a managed service in AWS, but it is not clear whenever Red Hat AMQ is camping base around Artemis. It helps in terms of selecting why someone would want to use ActiveMQ.
ActiveMQ is a messaging broker facilitating microservices communication and event management. It supports message queues, Camel routes, and asynchronous communication, enhancing integration capabilities and scalability with a network of brokers.ActiveMQ efficiently supports message transfer in IoT applications and third-party systems, acting as a hub for code distribution and data flow management. It integrates well with XML and protocols like MQTT, while its fast messaging, reliable...
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.
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.
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.
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. For additional functionality, I suggest making it easier to install and monitor the queues, topics, broker status, publisher status, and consumer status. Improved monitoring tools would help avoid needing to manually access the server for monitoring purposes.
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.
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.
The solution's dashboard needs improvement. Presently, we cannot see the actual count of the messages. Also, we encounter downtime issues while queuing messages for third-party systems. They need to improve this particular area.
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.
The tool needs to improve its installation part which is lengthy. The product is already working on that aspect so that the complete installation gets completed within a month.
The solution can improve the other protocols to equal the AMQ protocol they offer.
There are two areas that the product should improve. One, the solution needs to be maintained manually and two, there are some stability issues.
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.
For Kafka, we mainly use it for event sourcing. We have huge concurrent events. From the TPS point of view, it's like 100,000 transactions that need to be admitted from different devices and also from the different minor small systems. Those are best fit for Kafka. We have used it on the customer side, and we thought of giving a try to ActiveMQ, but we have to do a lot of performance tests and approval is required before we can use it for this scale. I think Kafka is best suited for the concurrent high volume of events. If these capabilities can be incorporated into ActiveMQ, it would be good to not have to use a second product. As a Q technology, everything in ActiveMQ works perfectly. But if that aspect of Kafka can be integrated or be a sub-component of ActiveMQ, it would be really great for enterprise-wide users.
This solution could improve by providing better documentation. IBM MQ has 30 years of experience to build upon and has had 30 years to grow and improve, while ActiveMQ does not have the same kind of heritage that IBM MQ has. In comparison, I find that IBM documentation is better, but it has had a lot more investment behind it. In the next release, I think that a roadmap would be interesting. If we look at ActiveMQ and the ActiveMQ Artemis which are parallel streams that might merge, but it's not clear on whether it will or when will it happen. That would be useful. Also, it is not that clear who offers what implementations. ActiveMQ is available as a managed service in AWS, but it is not clear whenever Red Hat AMQ is camping base around Artemis. It helps in terms of selecting why someone would want to use ActiveMQ.