Lead Data Engineer at a energy/utilities company with 51-200 employees
Real User
Top 20
2024-05-02T03:05:00Z
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
Top 5
2023-08-30T12:09:51Z
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.
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.
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.
Apache ActiveMQ is the most popular and powerful open source messaging and Integration Patterns server.
Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License
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.