The feature of ActiveMQ which I feel is good is its ability to have DLP, the later queues. If something goes wrong with the platform, it retries. Even if it fails, it goes to DLP, and later we can rescan the same event for processing. 

The ability to store the failed events for some time is valuable.

Since we use it outside of production, we mostly use the basic queueing concept of the tool. It's more about getting a queue up quickly for showcasing or trialing a bigger solution, not specifically for the features of ActiveMQ.

We like it because it's simple to start. You can run it in a Docker container; it is almost plug-and-play. 

The simplicity, that's the best quality of the product.

ActiveMQ brings the most value to small applications because it will not cost you very much to complete.

For reliable messaging, the most valuable feature of ActiveMQ for us is ensuring prompt message delivery. Losing messages could lead to critical issues, especially when different systems need to exchange time-sensitive information like financial records. 

Scalability is good as it has the concept of a "network of brokers", so there are no different queue names for distributed queues or physical queues.

The network of brokers scales by need but the queue name stays the same, hence the client does not need to worry about queue name change.

For example, if you use MQ from Oracle weblogic to implement messaging system with scalibility in mind, then you would implement one distributed queue on managed server and physical queues on each node, ideally the client connects to your distributed queue which has been configured to distribute messages to each physical queue by either round robin or weight policy etc.

In the above example, if you add new nodes then you have to add newly created physical queue to the distributed queue, or you have to inform the client what is the new physical queue name if your client choose to connect to the physical queue instead of distributed queue.

With the concept of the network of brokers, AMQ may add more brokers under load, but it always expose the same queue name to the client, so client won't notice the scale change and you don't need to config extra queues when it scales

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

The most valuable feature of this solution is the holding and forwarding.

ActiveMQ is very lightweight and quick.

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.

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.

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.

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

I am impressed with the tool’s latency. Also, the messages in ActiveMQ wait in a queue. The messages will start to move when the system reopens after getting stuck.

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

• Sequential message processing.
• Message broadcasting: There could be a use case sending the same message to all consumers. So as a producer, I broadcast the message to a topic. Then, whichever consumers are subscribed to the topic can consume the same message.
• JMX console: Provides a UI to visualize a list of queues and topics on the broker. We can see any pending message for particular topic/queue. It displays how many consumers are connected to a topic/queue. We can send a message from the JMX console to a topic/queue without the need of a producer to distribute the message.

• Price point and licensing are the most valuable features relative to our previous MQ solution (Websphere MQ).
• Apache provides Docker images on the public registry for multiple versions of ActiveMQ. The value of the Apache-provided Docker image is that it spares developers from having to manually install ActiveMQ software. Using Docker, I can get a working ActiveMQ server up and running in minutes with zero knowledge of how the software is installed or what configuration files need to be tweaked, etc. Also, I can spin up an ActiveMQ farm of Docker containers within minutes if I want to test things like clustering, HA, etc. For something like concept testing or R&D, this is a fantastic way to save time and money.
• Multi-protocol support: http://activemq.apache.org/protocols.html. As we began to explore integrating IoT solutions, ActiveMQ’s support of the MQTT protocol was very convenient!

The database and message queuing are valuable features. It is useful for apps that have a lot of messages as well.

It’s a JMS broker, so the fact that it can allow for asynchronous communication is valuable.

• Virtual topics supporting easy scalability of topic consumers
• Simple, yet flexible configuration of dead letter strategies
• The master-slave group with shared storage cluster topology

The ability to send large messages at decent speeds.

The valuable features are:

• Message queues
• Camel routes
• High availability
• Serialization of batch jobs
• Consumer/worker throttling
• Message durability

Reliable message delivery and mirroring.

Most valuable to us are fast asynchronous message queuing with message-level acknowledging and message persistency.