ActiveMQ Consulting & Services
AceMQ provides ActiveMQ consulting, migration, performance tuning and 24/7 support for ActiveMQ Classic 5.15 to 5.19 and 6.x and ActiveMQ Artemis 2.x, delivered by named senior engineers. The team of 11+ senior engineers has served 160+ customers in 26+ countries, with a 15-minute emergency response around the clock.
A senior engineer, not an SDR. No sales sequence attached.
Without a rip-and-replace migration to a different brokerFor production incident cover, see AceMQ ActiveMQ 24/7 support.
Customers
Partners
The Problem
Eight ActiveMQ problems that teams bring to AceMQ, across Classic 5.x and Artemis 2.x. They range from KahaDB growth and blocked producers to failover locks and brokers that no longer get security fixes. If one describes your week, that is where the review starts.
KahaDB journal files grow without bound and every restart takes longer than the last
One destination with slow consumers exhausts broker memory and producers block on unrelated queues
A failover pair both believe they hold the store lock, and messages land on the node nobody is reading
Network-of-brokers routing sends messages around the cluster instead of to the consumer that wants them
The dead-letter queue keeps filling and there is no documented, safe way to replay from it
The move from Classic to Artemis has slipped every year because nobody will own the address-model change
JMS clients hold stale connections after a broker restart and only a client redeploy clears them
The brokers are on a version that no longer receives security fixes and the upgrade path was never mapped
A good fit if you run ActiveMQ Classic or Artemis in production and want senior engineers who know its failure modes, whether you plan to stay on it or move off it.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy ActiveMQ.
How it breaks, and the fix
If destinations have no memory limits of their own, one slow consumer lets its queue fill the ActiveMQ broker's shared memory. Producer flow control then blocks producers on every queue, so a problem in one service stops the others too.
One slow consumer, one shared memory limit
Two producers, one ActiveMQ Classic broker, three queues
Broker memoryAll three queues drain as fast as the producers write. Broker memory sits well under its limit.
The invoices consumer slows down. Its queue fills the broker's shared memory, producer flow control kicks in, and both producers block, even on orders and audit, which had nothing wrong with them.
Each destination gets its own memory limit, the slow consumer a smaller prefetch, and its backlog pages to the message store. Producers keep sending and only invoices waits.
Producers blocked on queues that are healthy is one of the most common reasons teams call AceMQ about ActiveMQ Classic. The fix is configuration, not a new broker: a policy entry per destination with its own memoryLimit, consumer prefetch sized for the slowest consumer, a store cursor so the backlog pages to KahaDB, and a dead-letter policy with a documented replay path. On Artemis the same job is done by max-size-bytes and paging in the address settings, and AceMQ checks both.
Our Services
AceMQ runs four ActiveMQ service lines: architecture and optimization, Classic to Artemis migration, migration to RabbitMQ or Kafka, and performance tuning. A senior engineer leads each one, and any of them can roll into 24/7 support with a 15-minute emergency SLA.
We design and tune ActiveMQ Classic and Artemis deployments for the throughput, durability, and protocol requirements your applications demand.
Artemis is the next-generation ActiveMQ with a significantly improved architecture. We migrate Classic deployments to Artemis with minimal application changes.
When ActiveMQ has outgrown its architecture, we plan migrations to RabbitMQ, Kafka, or cloud-native messaging with full protocol and semantic mapping.
ActiveMQ performance issues are often caused by non-obvious configuration: store cursor policies, journal settings, and flow control thresholds. We know where to look.
Named senior engineers on your account — 15-minute emergency response, no ticket routing, no junior triage.
24/7 Support
AceMQ ActiveMQ support gives you named senior engineers and a 15-minute first response when production is down, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. The same response times apply to Classic and Artemis brokers.
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.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Every ticket is handled by a senior SME assigned to your account — not a pool of anonymous agents. Zero cold-start. No re-explaining your environment.
Any ticket can be escalated to a live session with your named engineer via calendar booking. No gatekeeping, no approval required — direct access, always.
Quarterly health checks on your deployment plus shared intelligence from our support customers — we surface risks before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
Commercial support for end-of-life ActiveMQ versions, with security fixes backported through OSSeva, so the upgrade happens on your schedule rather than the community's.
How It Works
An AceMQ ActiveMQ engagement runs in four stages: a broker assessment of 1 to 2 weeks, written findings within a week, changes made with your engineers, then a handover with runbooks. Each stage ends in writing, so your team sees what changes and why before anything does.
1–2 weeks
We review destinations, persistence adapter and store limits, memory usage per destination, failover topology and client connection settings across Classic and Artemis — then show you which of them your current traffic actually breaks.
Within a week
Prioritised findings with the reasoning attached, including a straight answer on whether an Artemis move is worth doing and what it would take.
Scoped per engagement
We change broker configuration, destination policies and client settings with your engineers rather than around them. Every change is staged per destination and reversible.
Ongoing
Runbooks for your destinations, DLQ replay and failover behaviour, plus 24/7 support with a 15-minute emergency SLA if you want it.
A senior engineer, not an SDR. No sales sequence attached.
Customer Success
ActiveMQ work from AceMQ, then, labelled as such, cases from the wider messaging practice on IBM MQ and RabbitMQ brokers. Each card links to the full write-up: the environment, what AceMQ assessed 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.
ActiveMQ
RabbitMQ
KubernetesRegional 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.
ActiveMQ
Spring Framework
Java
LinuxIndustrial 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.
ActiveMQJavaLinux
DockerHealthcare 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.
ActiveMQJavaLinuxSolutions
AceMQ covers ActiveMQ end to end: broker consulting and migrations, 24/7 support and incident management, proactive monitoring, managed brokers on your infrastructure or on AceMQ's, OSSeva patches for end-of-life Classic lines, and a fixed-price health check.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running ActiveMQ for you.
Compare the four ActiveMQ support tiersSide by side
ActiveMQ Classic (5.x and 6.x) and ActiveMQ Artemis 2.x are both Apache ActiveMQ brokers, but they store, address and replicate messages in different ways. Artemis is the usual path for teams invested in JMS and OpenWire. AceMQ supports both, and each row below answers one question about the move.
| Question | ActiveMQ Classic (5.x, 6.x) | ActiveMQ Artemis (2.x) |
|---|---|---|
| Where are messages stored? | KahaDB by default, or a JDBC database. | Its own append-only journal, or a JDBC database. |
| How are destinations modelled? | Queues, topics and virtual topics. | Addresses with anycast or multicast routing, and queues bound to them. Virtual topics have to be mapped to this model. |
| Which clients can connect? | OpenWire (JMS), AMQP, STOMP and MQTT. | Core, OpenWire, AMQP, STOMP and MQTT. Classic OpenWire clients can connect, and AceMQ checks each one before cutover. |
| How does failover work? | A shared-store master and slave that use a store lock, or a network of brokers. | Primary and backup pairs, using a shared store or replication. |
| Which versions does AceMQ support? | 5.15.x through 5.19.x and 6.x. CVE fixes are backported to 5.15.x through 5.18.x and 6.0 to 6.2 through OSSeva. | All 2.x releases, including the Artemis Operator on Kubernetes and Red Hat AMQ Broker on OpenShift. |
| What does a move involve? | Nothing, if Classic is stable and on a patched version. | Moving KahaDB data to the Artemis journal, mapping virtual topics to addresses, then a side-by-side run and a traffic cutover. |
For the full upgrade or migrate decision, read the ActiveMQ modernization guide. To see how long ActiveMQ and 20 other technologies get security fixes, see open source and vendor support windows compared.
One partner, not five
ActiveMQ rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on running, upgrading and migrating ActiveMQ Classic and Artemis, plus the AceMQ services for the brokers that usually run next to it.
FAQs
Nine answers on ActiveMQ from AceMQ: Classic or Artemis, supported and end-of-life versions, who answers when a broker fails, how an engagement starts, working with your team, slow Classic brokers, Artemis on Kubernetes, networks of brokers, and ActiveMQ as a service.
Still have questions about ActiveMQ? Email an Expert
AceMQ recommends Artemis for teams heavily invested in JMS and OpenWire, and a migration to RabbitMQ or Kafka for teams that need higher throughput or cloud-native integration. The right answer depends on your JMS dependency, throughput requirements and team familiarity. We help you evaluate both paths objectively.
AceMQ supports ActiveMQ Classic 5.15.x through 5.19.x and 6.x, and every ActiveMQ Artemis 2.x release. For Classic 5.15.x to 5.18.x and 6.0 to 6.2, which no longer receive upstream security fixes, CVE fixes are backported through OSSeva. We also advise on version selection, security patch status and end-of-life planning.
A named AceMQ senior engineer answers within 15 minutes, 24/7, when an ActiveMQ broker is down in production. Lower severities get a first response within 1 hour, 4 hours or the next day. The engineer who takes the first call stays on the case until the issue is resolved, for Classic and Artemis alike.
An AceMQ ActiveMQ engagement starts with a free consultation with a senior engineer, booked in our reply within 1 hour. Next comes a broker assessment of 1 to 2 weeks covering destinations, persistence, memory, failover and client settings. Written findings and a plan follow within a week, before anything changes.
Yes. AceMQ assigns a named senior engineer from its team of 11+ who works with your engineers rather than around them, changing broker configuration, destination policies and client settings together. Every change is staged per destination and reversible, and you keep the runbooks when the work is done.
The most common causes of a slow ActiveMQ Classic broker are underpowered storage (KahaDB is sensitive to disk latency), flow control thresholds set too low, message sizes that exceed the page cache, and slow consumers that let messages accumulate. AceMQ engineers diagnose these remotely from ActiveMQ JMX metrics and broker log analysis.
Yes. AceMQ deploys ActiveMQ Artemis with the ActiveMQ Artemis Operator on Kubernetes and configures persistent storage, anti-affinity rules and HA pairs. We also support Red Hat AMQ Broker, which is based on Artemis, on OpenShift.
AceMQ designs ActiveMQ networks of brokers for geographically distributed or load-balanced messaging. The work covers duplex connector configuration, consumer demand forwarding, cyclic network prevention, and message TTL tuning so messages do not loop between brokers forever.
Yes, in two ways. AceMQ can operate your ActiveMQ brokers inside your own cloud account, data centre or OpenShift cluster, with monitoring, patching, failover tests, upgrades and on-call, so messages never leave your network. Or AceMQ hosts and runs ActiveMQ Artemis on AceMQ infrastructure and your applications connect to a JMS broker endpoint. These are Tiers 3 and 4 of AceMQ's support ladder, and Classic 5.x, 6.x and Artemis 2.x are covered.
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.
Reviewed by Tyler Eastridge, Head of Operations · Last reviewed 15 Oct 2026
Let's talk
Our senior engineers handle ActiveMQ engagements end-to-end — from architecture review to 24/7 incident response. We reply within 1 hour to schedule your scoping call.
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.
