Emergency Incident Response
Production down, messages not flowing, or a broker that won't start. A senior engineer joins a live bridge within 15 minutes with direct access to diagnose — not a ticket acknowledgement.
ActiveMQ Support
Last reviewed by Scott Sternloff
AceMQ supports both ActiveMQ Classic and ActiveMQ Artemis in production — KahaDB corruption, producer flow control stalls, broker network splits, and JDBC store contention. Every ticket reaches a named senior engineer who already knows your broker topology.
Planning a build, upgrade or migration instead? See AceMQ ActiveMQ consulting and services.
Customers




Partners


Incident Triage
These are real symptoms from real ActiveMQ production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Producers hang or block — messages stop flowing with no error | Producer flow control state and memory/store/temp usage limits. In Classic this is almost always a destination hitting its memoryLimit with a slow or stalled consumer behind it. | Under 1 hour |
| KahaDB journal growing without bound, disk filling up | Which journal files are pinned and why — usually one unacknowledged message or a stuck durable subscriber holding a reference and preventing cleanup of every file after it. | 1–3 hours |
| Broker OutOfMemoryError under normal message volume | Consumer prefetch sizes against JVM heap. A default prefetch of 1000 across many consumers on large messages will exhaust heap long before the broker's own memory limits engage. | Under 2 hours |
| Messages stuck in a redelivery loop, DLQ growing fast | Redelivery policy, poison-message handling, and whether the consumer is throwing before or after acknowledgement — plus transaction boundaries if XA is involved. | 1–2 hours |
| Network of brokers split-brain — duplicate or stranded messages | Network connector configuration, duplex settings, and advisory message flow. Misconfigured networkTTL and conduitSubscriptions are the usual cause of message duplication across a broker mesh. | 2–4 hours |
| Artemis address full, paging to disk, throughput collapsing | Address settings — max-size-bytes, address-full-policy, and page-size-bytes — against actual consumer drain rate. Paging masks a consumer that can't keep up. | Under 2 hours |
| Failover not working — clients don't reconnect to the slave | Shared-store vs. replication topology, file lock acquisition on the shared store, and whether the client URI actually lists the failover transport with both brokers. | 2–4 hours |
Resolution times reflect typical ActiveMQ engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
Production down, messages not flowing, or a broker that won't start. A senior engineer joins a live bridge within 15 minutes with direct access to diagnose — not a ticket acknowledgement.
Every P1 closes with a written RCA: what failed, why, the fix applied, and the specific configuration or code change that prevents recurrence. Delivered as standard, not on request.
Prefetch sizing, memory and store limits, KahaDB vs. JDBC persistence selection, and consumer concurrency tuned against your actual throughput profile and message sizes.
Proactive alerts for CVEs affecting your exact ActiveMQ version — including the 2023 CVE-2023-46604 class of RCE issues — with tested upgrade paths and mitigation guidance.
Quarterly reviews of queue depth trends, broker resource headroom, and destination growth so you size ahead of demand rather than reacting to a full store.
ActiveMQ Classic to Artemis migration planning, version upgrades with rolling procedures, and migration off ActiveMQ to RabbitMQ or Kafka where that's the right call.
Why AceMQ
The same senior engineers stay on your account. They know your broker topology, your persistence choice, and your traffic pattern — so a P1 call starts with diagnosis, not twenty minutes of you explaining your environment.
You reach a senior ActiveMQ engineer directly by phone, email, or Slack. There is no help desk collecting information to pass along, and no escalation approval process standing between you and someone who can actually fix it.
Most vendors know one. We support ActiveMQ Classic 5.x and Artemis 2.x in production, including the migration between them — which matters because the two share a name and almost nothing else architecturally.
Engineers across 26+ countries and every time zone. Your 3am incident is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.
Quarterly health checks on your deployment plus shared intelligence across our support base. When a version-specific bug surfaces on one customer's cluster, every affected customer hears about it before it reaches their production.
ActiveMQ problems are often not ActiveMQ problems. We diagnose across the JVM, the OS, storage latency, network policy, and Kubernetes — because that's where the root cause frequently actually lives.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Escalation Path
Every tier reaches a senior ActiveMQ engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
AceMQ ActiveMQ support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, Amazon MQ or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
ActiveMQ support and migration work from AceMQ. Each card links to the full write-up: the broker estate, what AceMQ diagnosed or changed, and the result.
Higher Education Institution
A university ran ActiveMQ and an aging RabbitMQ side by side to stream student information system events. AceMQ assessed both estates and designed a single RabbitMQ target architecture.
Regional Payments Processor
Four live sessions to find why every producer on an ActiveMQ Classic 5.16 pair stalled when one settlement consumer slowed, and to give each destination its own memory limit.
Healthcare Benefits Administrator
A broker's data volume kept filling although its queues were nearly empty. The cause was a durable topic subscription for an application retired a year earlier.
Industrial Equipment Manufacturer
A manufacturer with ActiveMQ Classic brokers at plants and in the cloud had no inventory of versions or clients when CVE-2023-46604 landed. AceMQ contained it, found what was exposed, and patched brokers and clients.
Support options
AceMQ offers ActiveMQ support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for brokers your team runs, proactive monitoring that catches store, memory and CVE problems first, managed ActiveMQ on your own infrastructure, and fully managed Artemis on AceMQ infrastructure. Classic 5.x, 6.x and Artemis 2.x are covered in all four.
You run it, we back you up
Best for: Teams that run ActiveMQ Classic or Artemis themselves and need senior cover at 3am.
You run it, we watch it with you
Best for: Estates where a blocked producer or an unpatched OpenWire port is not an acceptable surprise.
We run it in your cloud or data centre
Best for: Regulated estates that must keep JMS traffic inside their own boundary.
We host it and run it, as a service
Best for: Teams moving off self-run Classic brokers who want a JMS broker without operating one.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs ActiveMQ day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for ActiveMQ
Support is one part of what AceMQ does for ActiveMQ. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
Our ActiveMQ support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, performance tuning, CVE and patch advisory, quarterly health checks, and upgrade or migration support. Every ticket is handled by a named senior engineer assigned to your account — there is no tier-1 triage layer and no per-incident charge.
Yes. We support ActiveMQ Classic 5.x and ActiveMQ Artemis 2.x in production, including migration between them. This matters more than it sounds: despite sharing the ActiveMQ name, Classic and Artemis have fundamentally different architectures, persistence models, and configuration. Many support vendors are genuinely strong in only one.
P1 emergencies — production down, messages not flowing, broker failure — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual, not best-effort targets.
Yes. We support Amazon MQ for ActiveMQ alongside self-managed deployments. Amazon MQ removes some operational surface but not the ones that cause most incidents — producer flow control, prefetch and memory tuning, destination design, and client-side failover configuration are all still yours to get right, and all still where we spend most diagnostic time.
Yes, and we will tell you honestly whether you should. We plan and execute migrations from ActiveMQ to RabbitMQ or Kafka with zero message loss, including protocol mapping, parallel-run validation, and canary cutover. We also frequently advise customers that their ActiveMQ deployment is fixable and a migration would be expensive theatre — the diagnosis comes first.
Yes. We support legacy ActiveMQ versions that no longer receive upstream patches, including bug workarounds and backported mitigations where official fixes are unavailable. Many regulated environments cannot upgrade on the community's timeline, and that constraint is a normal part of enterprise support rather than a disqualifier. For security fixes on ActiveMQ Classic 5.15 to 5.18 and on Artemis, AceMQ's OSSeva platform backports CVE patches, so an estate can stay on its version while the upgrade is planned.
Apache ActiveMQ is an open-source message broker from the Apache Software Foundation, released under the Apache license, and the project itself offers community help only. Commercial support comes from three places. Red Hat supports AMQ Broker, its own product built on ActiveMQ Artemis, for Red Hat subscribers. AWS supports Amazon MQ as a managed service. Independent providers such as AceMQ give production support for the Apache release itself, both ActiveMQ Classic and Artemis, on premises, in the cloud or on Kubernetes, with 24x7 plans and an escalation path to senior engineers.
ActiveMQ is a multi-protocol broker. Classic uses OpenWire as its native protocol and also speaks AMQP, STOMP and MQTT. Artemis adds its own core protocol alongside the same set. Both implement JMS, with ActiveMQ Classic 6.x and current Artemis releases moving to Jakarta Messaging. Support covers all of these, plus the things most deployments put around the broker: Apache Camel routes, the JDBC or KahaDB persistence layer, networks of brokers, and the Java client configuration where many production problems actually originate.
Yes, both ActiveMQ Classic and Artemis are actively maintained. ActiveMQ Classic 6.x is the current line. It requires Java 17 and moves from the javax.jms namespace to Jakarta Messaging, so an upgrade from 5.x touches application code and libraries as well as the broker. That work is worth planning because CVE patching only happens on maintained release lines, and ActiveMQ has had serious vulnerabilities, including a remote code execution flaw in the OpenWire protocol in 2023 that was widely exploited. If you cannot upgrade yet, we put mitigations in place, restrict exposure of the broker ports, and support the version you run while the upgrade is prepared.
Yes. AceMQ works on ActiveMQ in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your ActiveMQ environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how ActiveMQ is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running ActiveMQ for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email an ActiveMQ Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.