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.
