Apache Camel Support and Upgrades
Last reviewed by Tyler Eastridge
AceMQ helps teams that run Apache Camel routes in production plan the move from Camel 3 to Camel 4, keep up with a long-term-support line that Camel fixes for up to a year, and run the routes that connect to ActiveMQ, Kafka and RabbitMQ with senior engineers on call 24/7. AceMQ does not patch Camel releases the project has ended, and route code changes stay with your developers.
A senior engineer, not an SDR. No sales sequence attached.
Without rewriting your routesFor production incident cover, see AceMQ Apache Camel 24/7 support.
Customers
Partners
The Problem
Seven Camel problems that teams bring to AceMQ, from a Camel 3 route base nobody has moved to a dead-letter queue nobody reads. If one describes your quarter, that is where the work starts.
Camel 3 reached end of life on 23 December 2024 and routes are still running on it
Each Camel LTS line gets fixes for up to a year, so staying current is a yearly job and nobody owns it
The official 3.x to 4.0 guide starts from Camel 3.20, and a route base on 3.14 needs a step first
Camel 4 drops Java 11, so a route upgrade is also a JDK upgrade
Routes publish to RabbitMQ or Kafka through components Camel 4 removed or replaced, and nobody has listed which routes use them
A route fails on one broker endpoint, retries, and fills a dead-letter queue nobody watches
Routes run in a Spring Boot service, a Quarkus application and a standalone JVM, and each has its own upgrade path
A good fit if you run Camel routes across several services or brokers in production and need an upgrade plan, an LTS calendar, or senior engineers on call for the integration layer.
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 Apache Camel.
How it breaks, and the fix
A route reads from a source, runs two processing paths and writes to a broker. One path calls an endpoint that stops answering. How the route's error handling is set decides whether the failure stays on that path or backs up everything behind it.
One Camel route with a failing path
Source, two processing paths, producer, broker
The consumer reads from the source and both paths run. The producer writes to the broker without delay.
Path B calls an endpoint that stops answering. Redelivery attempts hold the exchange, the producer and broker behind it go quiet, and path A is blocked at the producer.
Redelivery limits and a dead-letter destination are set, the failing endpoint is fixed, and the held messages are replayed in order.
Camel routes carry exchanges between endpoints, and each route has an error handler. Without a redelivery limit and a dead-letter destination, a failing endpoint keeps retrying the same exchange while the exchanges behind it wait, and a producer shared with another path can stall too. The operations review reads the error handlers, the redelivery policy, the concurrency of each consumer and the dead-letter queues against how your brokers behave, so the failure stays on the path that caused it and the backlog can be replayed. It also checks who watches the dead-letter queue, which is where many routes lose messages quietly.
Our Services
AceMQ runs five Camel service lines: Camel 3 to 4 upgrade planning, 24/7 production support, a route and broker operations review, LTS cadence planning and a fixed-scope health check. Support can follow any of them. AceMQ does not patch Camel releases the project has ended.
A written plan for moving a Camel 3 route base to a Camel 4 LTS line, with the removed components, the JDK move and the order of routes mapped.
24/7 engineers for Camel routes in production: stuck consumers, redelivery loops, memory pressure and broker connection failures.
A fixed-scope review of how routes behave when a broker or a downstream system misbehaves.
A yearly plan for staying on a supported Camel line, so each LTS move is scheduled before the previous line ends.
The fixed-scope entry engagement: a written report on how your routes and runtimes are configured, which your team can act on with or without AceMQ.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ gives you an engineer and a 15-minute first response when Camel routes fail in production, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes for Camel itself come from the Apache project, or from Red Hat for its own build: AceMQ produces none.
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.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Release notes and lifecycle dates read against your environment, with an upgrade plan that fits your change windows.
How It Works
An AceMQ Camel engagement runs in four stages: a scoping call with a quote within 1 hour, a route inventory, a written plan, then waves or ongoing cover. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: Camel versions, runtime (Spring Boot, Quarkus or standalone), JDK, the brokers and systems the routes talk to, and what has prompted the question. A quote request is answered within 1 hour.
Scoped per estate
Every route listed with its Camel components, runtime, JDK and endpoints, checked against the removed and replaced components in Camel's migration guide. The inventory is written down and your team keeps it.
Scoped per estate
A recommendation in writing: the Camel line to land on, the order of the routes, the JDK and runtime moves it needs, and the changes your developers own. A step to Camel 3.20 comes first where a route base is older.
Ongoing or fixed scope
Pilot routes first, then waves with a rollback for each. The work ends with a standard route configuration and a runbook for the next LTS move. You can stop there or add 24/7 cover.
A senior engineer, not an SDR. No sales sequence attached.
Typical engagements
Typical Camel engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers.
Solutions
AceMQ covers Apache Camel end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Apache Camel on your infrastructure and fully managed Apache Camel on AceMQ infrastructure, plus end-of-life versions.
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 Apache Camel for you.
Compare the four Apache Camel support tiersSide by side
Camel 3 is over, Camel 4 has two supported LTS lines on 4 November 2026, and Red Hat sells its own build with a longer window. The lines differ in end-of-life month, supported Java versions and how you get there. Each row below answers one question.
| Question | Camel 3.x | Camel 4.18 LTS | Camel 4.22 LTS | Red Hat build of Camel 4 |
|---|---|---|---|---|
| Where does upstream stand? | Ended. Camel's blog of 23 December 2024 says Camel 3 is end of life with no further releases. | End of life February 2027. Latest release 4.18.5 (11 October 2026); 4.18.0 shipped on 17 February 2026. | End of life August 2027. Latest release 4.22.2 (22 October 2026); 4.22.0 shipped on 11 August 2026. | A Red Hat product: Full Support to 30 October 2028, Maintenance Support to 30 October 2029 and ELS-1 to 29 October 2030 (Red Hat data). |
| Which Java versions? | Camel 4 drops Java 11, so a Camel 3 route base on Java 11 changes JDK as part of the move. | Java 17 and 21. | Java 17, 21 and 25. | Set by Red Hat's build. AceMQ reads its release notes for your version. |
| How do you get there? | You are here. Camel's guide starts from Camel 3.20; a route base on an older 3.x, such as 3.14, first moves to 3.20 with the 3.x upgrade guide. | From Camel 3.20 or higher with the 3.x to 4.0 migration guide, then the 4.x upgrade guide between 4.x releases. | The same path, or from 4.18 with the 4.x upgrade guide. | Through Red Hat's documentation for its build and your subscription. |
| Who patches it? | Nobody upstream, and AceMQ does not patch ended releases. | The Apache Camel project, until end of life in February 2027. | The Apache Camel project, until end of life in August 2027. | Red Hat, under a subscription. AceMQ is an independent provider, sells no Red Hat subscription and produces no patches. |
| What does AceMQ do? | Inventory the routes, plan the move and run the waves, with the code changes listed for your developers. | Run the routes in production, 24/7, and plan the next LTS move before this line ends. | Run the routes in production, 24/7, and keep the yearly LTS calendar. | Run and support the routes beside your subscription; the support agreement with Red Hat stays yours. |
| Who should stay put? | A team with a patch source and a dated plan to leave. Otherwise this line is a risk to schedule. | A team mid-migration that will land on 4.22 before February 2027. | A team that wants the longest upstream window on today's list and can move about once a year. | A team that wants a vendor accountable for Camel and already buys Red Hat subscriptions. |
For the other ways to buy support across messaging and integration software, read enterprise support plans compared. Whether to keep Camel or replace it with a commercial platform is a separate decision: see AceMQ's MuleSoft and Boomi pages.
Camel's migration guide lists removed components and, for most, a replacement. These rows are the ones that touch brokers, monitoring and in-JVM hand-offs, read from the guide on 4 November 2026. AceMQ checks each route against the full list, not only these.
| Camel 3 component | Camel 4 status in the migration guide | What to check on your side |
|---|---|---|
| camel-rabbitmq | Removed; the guide names spring-rabbitmq-component as the replacement. | Re-point every RabbitMQ route to the replacement and test against your real exchanges, queues and acknowledgement settings. |
| camel-vertx-kafka | Removed; the guide names camel-kafka as the replacement. | Move the routes and compare consumer group, offset and commit settings with what ran before. |
| camel-opentracing, camel-zipkin, camel-microprofile-metrics | Removed; the guide names camel-micrometer and camel-opentelemetry as replacements. | Dashboards and alerts that read these traces and metrics need rewiring. |
| camel-vm, camel-directvm | Removed; the guide names camel-seda and camel-direct as replacements. | Route-to-route hand-offs inside one JVM, where queue and blocking behavior matter. |
| camel-xstream, camel-johnzon | Removed; the guide names camel-jacksonxml, and camel-jackson, camel-fastjson or camel-gson, as replacements. | Test with real payloads, because a different library sits behind the data format. |
| camel-cdi | Removed; the guide names camel-spring-boot and camel-quarkus as replacements. | Routes bootstrapped through CDI move to one of the two runtimes. |
| camel-test modules based on JUnit 4 | Removed; all test modules now use JUnit 5. | Route tests are rewritten for JUnit 5 by your developers. |
The full list of removed components is in Camel's 3.x to 4.0 migration guide (camel.apache.org/manual/camel-4-migration-guide.html) as read on 4 November 2026.
One partner, not five
Apache Camel 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 support options, plus the AceMQ services around Camel: ActiveMQ, Kafka, RabbitMQ, Boomi, MuleSoft and the JDK.
FAQs
Five answers on Apache Camel from AceMQ: the Camel 3 to 4 path, which line to run, end-of-life patching and what AceMQ does not sell.
Still have questions about Apache Camel? Email an Expert
Camel's official 3.x to 4.0 migration guide covers migrating from Camel 3.20 or higher, and says users on older 3.x releases, such as 3.14, should first upgrade to 3.20 with the 3.x upgrade guide. Camel 4 supports Java 17 and drops Java 11, and the guide lists removed components and API changes. AceMQ turns that into an inventory of your routes, a written plan and a wave order, and lists the code changes for your developers.
Camel says its LTS releases receive bug and security fixes for up to one year. On 4 November 2026 the download page lists 4.22.x LTS (first release 4.22.0 on 11 August 2026, end of life August 2027, Java 17, 21 and 25) and 4.18.x LTS (first release 4.18.0 on 17 February 2026, end of life February 2027, Java 17 and 21). The two lines started six months apart and each gets about a year of fixes, so a team that stays on LTS lines moves roughly once a year, and AceMQ builds that into a calendar.
No. AceMQ plans upgrades, operates routes and gives 24/7 production support, but it does not produce patches for Camel releases the project has ended. For that, see OSSeva at osseva.io. AceMQ is an independent provider and sells no Red Hat subscription; the Red Hat build of Apache Camel 4 is a Red Hat product with its own support life cycle.
Yes. AceMQ works on Apache Camel 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 contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Apache Camel 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 Apache Camel is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Camel routes, tells you what to inventory first, and quotes the work. Quote requests are answered within 1 hour.
Production incident right now?Email an Apache Camel 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.
