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