ActiveMQ Reviews

We use the solution to manage the event messages by controlling the flow rate, handling error resubmissions, and ensuring the controlled processing of events.

The solution provides the best support services. It prevents losing messages with reliable techniques. Also, we can set thresholds for messages using it.

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.

We have been using the solution for the last six months.

The solution's stability needs improvement.

We have around 300 applications for the solution.

The solution's technical support is good. Although, it took longer to respond to some of the queries related to licensing and stability.

Positive

I used JMS before.

The solution is less expensive than JMS and Kafka.

I rate the solution an eight out of ten.

Most architecture nowadays requires too much performance. We can use products like ActiveMQ to improve our architecture.

I implemented a micro-services based architecture and did some of the communication via queues. I used actors with the Akka framework, and not only threads in Java.

The most important feature is that it's best for JVM-related languages and JMS integration.

The product is really straightforward. All the operations that you use are pretty simple and worked fine.

The deal is to write the correct logic.

Message Management: Better management of the messages. Perhaps persist them, or put in another queue with another life cycle.

To clarify, it needs some queues in memory with the same abstract logic that ActiveMQ provides. An interesting example could be the embedded Redis framework, or the Derby database for integration tests.

ActiveMQ does not persist the messages in the queue. So it would be fine if active has that feature, or some way to do it. So you can grab that message any time during the application lifecycle.

Apache Kafka has that feature.

The improvement could be the availability to persist the message in the
queue for any time along the app running.

Testing: I did not find a correct way to test the integration using Java, but rather only with manual testing.

We did not encounter any stability issues.

There were no scalability issues. With a good strategy, we can scale onto large systems using ActiveMQ.

I would give technical support a rating of 10/10. Despite the doubts that I encountered during the development, I could get the answer in the documentation.

The initial setup is very easy. You don't need to install anything. Just run the start command or put the URL in the browser.

I think the software is free.

We evaluated Apache Kafka and also RabbitMQ. The choice was about the better integration with JMS.

I fully recommend this product, but you need to have some expertise working with JMS and asynchronous tasks. You also need a correct strategy, or at least think about one.

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.

The primary use case of this solution is to send messages between applications.

In all messaging applications, typically, sending and receiving messages is the most important and critical feature that we see our customers use.

The solution can improve the other protocols to equal the AMQ protocol they offer.

I have been using the solution for a couple of years.

The solution is fairly stable. But we are using it in Development, not in production, so I'm probably not the best judge of stability in general.

We don't see the solution used as much as Apache Kafka by our customers, but it is scalable.

We are supporting almost all the messaging platforms for our connectors. So I have been using other messaging products as well.

The initial setup is straightforward and only takes a few minutes. We have experience so it doesn't take a whole lot of time.

The implementation was completed in-house.

Since we are using the open-source version of the solution we do see a return on investment.

We use the open-source version.

I give the solution a six out of ten. 

Our customers would use the solution in any model. We have to test with the on-premise deployments and run on an EC2 cloud.

We have about ten users in our organization.

We do not require any people for deployment or maintenance.

Whenever we need support we get it from the online community.

I do not recommend ActiveMQ over Apache Kafka partly because I don't know who provides support for the solution.

When our clients are looking for AMQ protocol support specifically ActiveMQ is our recommendation.

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.

One of the most important features of ActiveMQ is the ability to set up a network of brokers, and the ability to forward the message to another broker in the network, where there is a demand for messages from a consumer. These brokers could span over WANs and geographies. The messages will get forwarded to the broker where the demand is, which is what makes this a distributed messaging system.

The 'Shared nothing' configuration, where each broker has its own DB instance, is very important. It ensures that every message is accounted for and persisted in the DB to be replayed in case of failure.

Load balancing is important when huge numbers of messages are coming in. The messages get distributed to all the brokers, which are connected. In case of failure of any one broker, the message automatically gets routed to other brokers, ensuring no loss of messages.

By default, the failover protocol uses a random algorithm to choose one of the underlying connectors. If the connection fails, the transport will pick another URI and try to make a connection. The network automatically passes messages to connected brokers that have interested consumers. The failover protocol ensures clients do not need to be manually restarted in the case of a broker failure. As soon as the broker becomes available again, the client will automatically reconnect.

We also appreciate the easy setup of persistent messages using a DB like Oracle.

The master-slave relationship between brokers needs some improvement.

In case of shared architecture between brokers (i.e., both brokers sharing same the DB instance), one becomes master and the others become slaves. In this situation, the master always consumes the message and the slave is always in a dormant condition. This makes load balancing impossible. Probably this can be improved upon.

Another area of improvement is the monitoring console, which is kind of rudimentary. There is no facility to trace the entire XML message and take corrective action, such as resending the message.

If these facilities are added, it will be very good.

I have been using ActiveMQ for 2 months.

We have not had any stability issues.

We have not tested scalability.

We considered switching from WebLogic JMS, since we faced many issues including message affinity and lost messages.

The initial setup was straightforward.

The pricing and license policies are pretty good.

We use this product to provide us with a real time solution. It has helped us find ways to:

• Message or pass data, aside from hitting and saving data in a database.
• Perform asynchronous messaging.
• Queue database messages so requests are serial, if needed.
• Scale the application by increasing worker nodes via topics and queue load balancing.

I appreciate many features including queue, topic, durable topic, and selectors. I also value a different support for different protocols such as MQTT and AMQP. It has full support for EIP, REST, Message Groups, UDP, and TCP.

I would like to see the following improvements:

• The way it stores data
• Needs to focus on a certain facet and be good at it, instead of handling support for most of the available message brokers.
• For example, AMQP is a different flavor of message broker. However, adding it to ActiveMQ dramatically shifts its methodology and design. It can handle it, but it will be bad at it. Either you create a new forked solution of AMQ with AMQP and align only with AMQP, or just don't do it.

There were stability issues. With a network of brokers, you get a lot of issues, especially if you have the publisher and consumer using the same channel or connection, on different topics and/or queues. It’s causing a lot of issues and weirdness.

Setting up a network of brokers is problematic. The best thing is to do master-slave with a cold backup.

It is open source, so you get a very good response from the community. I heard Fuse is good, but I never talked to them.

We used to deploy Apache Kafka, as it was best for big data.

The initial setup is easy, and you can embed the ActiveMQ on the test.

Depending on the problem, AMQ resolved nearly everything. However, it may not be suitable for complex issues.

For what and where it is used, depending on the project, it will be very good.

For example, if I need to use a web application that will have ability to have an embedded message queue, it can work perfectly.

But if I need to have solution for big data, it may not be the best, especially for large streaming data. It varies by use.

Vet other solutions before implementing anything. Run multiple tests, like multi- thread and flood it with messages, as well as large messages, and combinations of both. See how it behaves.

We use this solution for messaging.

For any messaging system, I think that messaging, in general, is fundamental to software development.

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.

I have had experience with ActiveMQ, on and off, for approximately five years.

I have not used it heavily in a production environment, but at the moment, I don't have any issues to report. 

I am currently working with some clients to investigate some stability issues they are experiencing, but it could be the result of the way it was implemented.

In terms of performance, I have not any extensive performance tests as a comparison.

I have looked at other messaging providers, and I don't think that it's any worse than any other solution available. I think that it's reasonable.

There is a little bit of community support, but when you have 30 years of experience, it is not difficult to work out. With messaging, you pick up on new messaging products and you can fill in the gaps very quickly.

The initial setup is straightforward.

I have also had experience with IBM MQ for the last 30 years. I am comparing between different products and messaging scenario expertise.

I work in consultancies with many clients who have many different versions.

All messaging whether it's ActiveMQ, Amazon MQ which is Active MQ, or it's IBM MQ, they are all very similar, they all have strengths and weaknesses.

We have clients from small to large enterprises.

I would recommend this solution but it depends on the requirements. For example, what kind of support does the vendor want? What kind of managed services do they want? It is important because you can run ActiveMQ on AWS to get a managed service. It always depends on what their clients are looking for.

I'm impressed, I think that ActiveMQ is great.

I would rate this solution a seven out of ten.