ActiveMQ

What is ActiveMQ?

Apache ActiveMQ is one of the longest-serving open-source message brokers: queues and topics, durable subscriptions, transactions, and the full JMS API that a generation of Java enterprise software was built against. Its protocol breadth — OpenWire, AMQP, MQTT, STOMP — made it the interoperability broker, and it remains the path of least resistance wherever JMS is a requirement rather than a choice.

Classic versus Artemis — the fork that matters

“ActiveMQ” is two brokers. Classic (5.x) is the legacy line: stable, ubiquitous, architecturally dated. Artemis — built from HornetQ’s donated codebase — is the designated successor: a rewritten core with non-blocking I/O, a faster journal-based store, and substantially higher throughput. New deployments should default to Artemis; the Classic-era knowledge base (KahaDB tuning folklore, network-of-brokers patterns) doesn’t transfer cleanly, which is the real migration cost. Against RabbitMQ, the differentiator is JMS fidelity and Java-ecosystem gravity; against Kafka, the same queue-versus-log distinction as always — ActiveMQ deletes on consumption and excels at task semantics, not replayable streams.

Operational sharp edges

Persistent messaging is disk-bound: journal storage speed caps broker throughput. High availability means shared-store or replication pairs — replication without careful quorum configuration invites split-brain. And the classic production incident is unbounded queue growth from a dead consumer: producer flow control and destination policies exist precisely so a full disk doesn’t take the broker down.

What people get wrong

• Choosing Classic for greenfield because tutorials are older and more numerous.
• Ignoring prefetch settings — Classic’s consumer prefetch defaults cause one slow consumer to hoard messages while others starve.
• Treating it as Kafka and wondering where replay went.

Primary source: Apache ActiveMQ documentation

ActiveMQ’s Protocol Flexibility

A distinguishing feature of Apache ActiveMQ is its support for multiple standard messaging protocols — including AMQP, MQTT, STOMP, and OpenWire — within a single broker, letting heterogeneous systems written against different protocol expectations all connect to the same underlying message infrastructure. This protocol flexibility has made it a common choice in enterprise environments with a mix of legacy systems and newer services that weren’t all built around the same messaging standard from the start, though this flexibility comes with somewhat more operational complexity than more narrowly focused, single-protocol alternatives, a tradeoff that has led some newer architectures to prefer more specialized tools (Kafka for high-throughput event streaming, or cloud-native managed queues) over a general-purpose multi-protocol broker like ActiveMQ.