What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
The most valuable feature of this solution is the holding and forwarding.
What needs improvement?
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 how long have I used the solution?
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.
What do I think about the stability of the solution?
ActiveMQ is a very stable solution.
What do I think about the scalability of the 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.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What about the implementation team?
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.
What's my experience with pricing, setup cost, and licensing?
There are no fees because it is open-source.
There are no fees to begin using it.
What other advice do I have?
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.
Which deployment model are you using for this solution?
On-premises
*Disclosure: I am a real user, and this review is based on my own experience and opinions.