ActiveMQ Support: Who Supports Classic and Artemis in Production

Apache ActiveMQ has no vendor. Support comes from the community, from Red Hat for its AMQ Broker distribution, from Amazon for brokers it manages in Amazon MQ, or from an independent support provider for the ActiveMQ you run yourself. Which one applies depends on which ActiveMQ you run, because Classic and Artemis are now separate Apache projects.

First, which ActiveMQ

ActiveMQ Classic (the 5.x and 6.x line) and Artemis are different brokers with different storage, addressing and HA models. In November 2025 the Apache ActiveMQ PMC voted to make Artemis its own top-level project. Both are actively maintained. A support provider should say plainly which of the two they cover; the differences are laid out in ActiveMQ Classic vs Artemis.

Community support

The project's mailing lists and issue trackers are free and often reach the people who wrote the code. Apache's own support page is candid about the limit: help is volunteered, so the time available to resolve your issue is often limited. It suits development questions. It does not suit a production outage.

Red Hat AMQ Broker

Red Hat sells AMQ Broker, a supported distribution built on Artemis, with production support under a Red Hat subscription. It fits estates already standardised on Red Hat. It is a distribution with its own lifecycle, so it is a move onto Red Hat's product, not support for the Apache release you already run.

Amazon MQ

Amazon MQ runs ActiveMQ Classic as a managed service and handles provisioning, patching of the operating system and broker, and infrastructure. AWS supports the service. Destination design, client behaviour, slow consumers and KahaDB growth remain yours.

Independent ActiveMQ support

For the Apache release on your own servers, production support comes from an independent provider. Apache's support page lists several firms (checked 21 September 2026), among them OpenLogic, HYTE, meshIQ, Savoir Technologies, Tomitribe and Yupiik. AceMQ provides 24/7 ActiveMQ support for both Classic and Artemis with a 15-minute emergency SLA, covering KahaDB corruption and store growth, producer flow control, network-of-brokers problems, failover, JMS client issues and upgrades.

What an ActiveMQ support contract should cover

ActiveMQ is open source under the Apache License from the Apache Software Foundation, so you are not buying a licence. You are buying people. A useful contract for production environments covers five things.

• Incident response. A 24x7 plan with a named escalation path, for the failures that cause downtime or message loss: a full KahaDB persistence store, producer flow control, a stalled network of brokers, a failed high-availability pair.
• Broker configuration and topology. Destination policies, memory and store limits, replication and failover, and deployment on virtual machines, containers or Kubernetes.
• Protocols and clients. ActiveMQ is multi-protocol: OpenWire, AMQP, STOMP, MQTT and WebSockets, with JMS 1.1 in the 5.x line and Jakarta Messaging in 6.x. Most connection problems sit between a client library and one of those protocols, often with Apache Camel in the middle.
• CVE patching and version upgrades. The project fixes vulnerabilities in current releases. A provider should tell you which CVEs affect your version, and either get you to a patched release or carry the fix for you. The move from ActiveMQ 5.x to 6.x is more than a version bump: 6.x requires Java 17 and the Jakarta namespace, so client applications change too.
• An upstream route. When the cause is a defect in the codebase, someone has to raise it with the project and follow it through. Ask whether the provider has done that before.

The ActiveMQ incidents that actually page people

• KahaDB that never shrinks. ActiveMQ Classic can only delete a journal file when every message in it has been consumed. One unconsumed message in a forgotten queue or a growing dead letter queue pins gigabytes of log files until the store limit is reached and producers block. Finding the destination that holds the oldest file is the fix, and it is not obvious from the console.
• Producer flow control. When a destination or the broker hits its memory or store limit, producers are throttled or blocked outright. To the application this looks like a hang. The limits, the cursor type and the policy per destination all interact.
• Slow consumers and prefetch. A large prefetch hands hundreds of messages to one consumer while others sit idle, or a slow topic subscriber forces the broker to hold messages for everyone. Prefetch size and slow consumer policies are per-workload decisions.
• Stuck messages in a network of brokers. Messages forwarded across a network of brokers strand on a broker with no consumer, because of how conduit subscriptions and network TTL were configured. It works in testing and fails when consumers move.
• Artemis paging and journal pressure. On Artemis, an address that exceeds its memory limit starts paging to disk. Throughput drops sharply, and a journal on slow or shared storage makes it worse. Address settings and storage are where to look.
• Failover that did not happen. Shared-store master and slave pairs depend on file locking that some network file systems do not honour, and Artemis replication needs a quorum design to avoid split brain. Both are found in a rehearsal or in an outage.

Moving from ActiveMQ Classic to Artemis

Many Classic estates are weighing the move. Artemis speaks OpenWire, so existing JMS clients can often connect unchanged, and it also supports AMQP, MQTT, STOMP and its own core protocol. The differences that need testing are addressing, where Artemis uses addresses and routing types in place of Classic's queues and topics, along with advisory messages, virtual topics, scheduler behaviour, and any broker plugins or custom interceptors. Persistent messages can be exported and imported, but most teams run both brokers side by side and drain the old one. A support provider that knows both code bases can tell you which of your destinations will need client changes before you start.

What to check before you sign

• Classic, Artemis, or both, and on which versions.
• Whether 24/7 means an engineer or an acknowledgement.
• Whether they will support a version the project no longer patches, and what that covers.
• Whether they can also run the migration if you decide to leave: to Artemis, or to another broker. The ActiveMQ modernization guide and the ActiveMQ vs RabbitMQ comparison cover that decision.