JBoss EAP and WildFly Support
Last reviewed by Tyler Eastridge
AceMQ gives enterprises that run JBoss EAP or WildFly in production 24/7 support from a senior engineer, a planned move from EAP 7 to EAP 8, and a review of datasources, thread pools and the JVM. WildFly is a community project and JBoss EAP is Red Hat's product: AceMQ is an independent provider: it is not a Red Hat reseller, sells no EAP subscription and works beside one where you hold it.
A senior engineer, not an SDR. No sales sequence attached.
Without rewriting your applicationsFor production incident cover, see AceMQ JBoss 24/7 support.
Customers
Partners
The Problem
Seven JBoss and WildFly problems that teams bring to AceMQ, from a community server with nobody to call to a datasource pool that stays dead after a failover. If one describes your quarter, that is where the work starts.
WildFly runs a production service and nobody can say who to call when it misbehaves, because the project is a community one
EAP 7 passed Red Hat's Maintenance Support on 30 June 2025, so fixes now depend on a paid Extended Life-cycle Support (ELS) add-on
Moving to EAP 8 means Jakarta EE 10, and Red Hat's own guide calls the javax to jakarta package rename the biggest change in the move
An application that deployed cleanly on EAP 7 needs attention before it deploys on EAP 8, and nobody knows which deployments are affected
Request threads pile up and the datasource pool runs dry after a database failover, because connections to the old primary were never validated
Standalone configuration files differ from node to node because someone changed a setting in the admin console and nobody wrote it down
WildFly ships a new release every few months (41 on 16 July 2026, 42 on 22 October 2026) and production is several releases behind with no routine for catching up
A good fit if you run WildFly or JBoss EAP across several applications and need senior engineers on call, a vendor-neutral EAP 8 plan, or a review of how your servers behave during a failure.
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 JBoss.
How it breaks, and the fix
The primary database goes down and a replica takes over. The application server still holds a pool of connections to the old primary, and the request threads that need one wait on it. How the datasource validates and flushes its connections decides whether the server recovers by itself.
Database failover seen from the application server
One datasource pool, one primary database, two replicas
Request threads take connections from the pool, which leads to the primary. Both replicas follow the primary with little lag.
The primary goes down. Pooled connections to it are dead but still handed out, so threads block waiting on answers and the worker threads fill up. Replica 1 is promoted while it is still behind.
Replica 2, which had caught up, takes over, and the pool is flushed so it stops handing out connections to the old primary. Replica 1 is held back until its lag drains.
A WildFly or EAP datasource keeps a pool of open connections. When the database behind it fails over, the pool learns about it only when a connection is used or checked. The datasource subsystem has attributes for this: validate-on-match checks a connection as it is handed out, background-validation checks idle ones on a timer, and flush-strategy sets how much of the pool is dropped when a connection fails (Red Hat's EAP attribute reference gives FailingConnectionOnly as the default). Red Hat's attribute reference notes that validate-on-match is usually not combined with background validation, because the checks would repeat each other. A pool smaller than the number of request threads adds a second queue in front of the database, and a long blocking timeout makes callers wait in it. The tuning review reads these settings against how your database actually fails over and against the size of the Undertow worker pool, so the failure is rehearsed before it happens.
Our Services
AceMQ runs five JBoss service lines: 24/7 production support, EAP 7 to EAP 8 upgrade planning, a server tuning and security review, exit planning to Tomcat, and a fixed-scope health check. Support can follow any of them. AceMQ sells no EAP subscription and produces no EAP patches.
24/7 engineers for the application server layer in production: stuck threads, exhausted datasource pools, failed deployments, memory pressure and security-configuration failures.
A written plan for moving EAP 7 estates to EAP 8, with the server-side work run by AceMQ and the application changes listed for your developers.
A fixed-scope review of the settings that decide how a server behaves under load and during a failure.
A platform assessment for applications that use only the web tier, with a written account of what Tomcat does not provide.
The fixed-scope entry engagement: a written report on how your servers are configured and where they are exposed, 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 a WildFly or EAP server fails in production, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Patches for EAP still come from Red Hat and WildFly fixes from the project: AceMQ produces neither.
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.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ JBoss engagement runs in four stages: a scoping call with a quote within 1 hour, an inventory of servers and deployments, a written plan, then the work or a handover. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: EAP and WildFly versions, standalone or domain mode, the JDK, whether servers run on VMs or in containers, and what has prompted the question. Your Red Hat subscription status is yours to settle with Red Hat. A quote request is answered within 1 hour.
Scoped per estate
Every server listed with its version, JDK, operating system and configuration: datasources, Undertow and thread pools, security settings, JVM flags. Every deployment listed with the packages it imports. The inventory is written down and your team keeps it.
Scoped per estate
A recommendation in writing for each application: stay and harden, move to EAP 8, move to a newer WildFly, or move the web tier to Tomcat. Each option carries its risks and who changes what. The plan ends before anything is touched.
Ongoing or fixed scope
Pilot servers first, then waves with a rollback for each. The work ends with a documented standard configuration and a runbook for the next release. You can stop there or add 24/7 cover.
A senior engineer, not an SDR. No sales sequence attached.
EAP 7 to EAP 8
Red Hat's EAP 8 migration guide calls the javax.* to jakarta.* package rename the biggest change in moving an application from EAP 7 to EAP 8. That rename lives in application code, so the work splits in two: AceMQ plans and runs the server side, and your developers or your own tooling change the sources.
Find the javax
List each deployment and what it imports: javax packages, bundled Jakarta EE libraries, descriptors. Red Hat's guide names the Migration Toolkit for Runtimes, a rule-based set of tools for analyzing Java applications before a migration. AceMQ reads its report next to the server configuration.
Server side
The EAP 8.0 guide lists what was removed, among them OSGi support, the PicketLink subsystem, the legacy security subsystem and security realms. Each datasource, security domain and subsystem setting is mapped to its EAP 8 form in a written diff.
Prove it
EAP 8.0 provides Jakarta EE 10. Stand an EAP 8 server up beside the running EAP 7 and deploy the applications that are already Jakarta-ready first. Anything still on javax goes back to its developers with the failing import named.
Cut over
Applications move one wave at a time and the EAP 7 server stays warm for rollback. The move does not share a window with a JDK or database change, so a failure has one cause.
Typical engagements
Typical JBoss and WildFly engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Financial Services Application Team
24/7 production support for WildFly and JBoss EAP servers, with a written inventory and a plan for moving the EAP 7 estate to EAP 8.
Java
KubernetesMid-Sized Distribution Company
A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.
JavaOpenJDK
DockerKubernetesSaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
JavaKubernetesDocker
PrometheusSolutions
AceMQ covers JBoss 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 JBoss on your infrastructure and fully managed JBoss 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 JBoss for you.
Compare the four JBoss support tiersSide by side
JBoss EAP is Red Hat's supported product. WildFly is the community project behind it, and Tomcat is a smaller runtime that implements a subset of Jakarta EE. The choice changes who builds the server, who answers a failure and what your applications may use. Each row below answers one question.
| Question | JBoss EAP with a Red Hat subscription | WildFly with AceMQ | Apache Tomcat |
|---|---|---|---|
| Who builds and supports the software? | Red Hat. Its subscription covers production-ready code, life-cycle management and a choice of supported versions, on your servers or as a managed service on Azure, AWS and Google Cloud (Red Hat product page). | WildFly is a community project sponsored by the Commonhaus Foundation. AceMQ supplies engineers for the server in production and takes defects in WildFly's own code to the project. | The Apache Tomcat project. AceMQ runs Tomcat support separately: see the Tomcat support page. |
| Which Jakarta EE level does it give you? | EAP 8.0 provides Jakarta EE 10. EAP 7 is on the javax namespace. | It is set by the WildFly release you run. WildFly 42.0.0.Final came out on 22 October 2026, and AceMQ reads the release notes of the exact version before it plans a move. | Tomcat 10.1 targets Jakarta EE 10 and 11.0 targets Jakarta EE 11, but Tomcat implements only a subset of the specifications (Servlet, Pages, Expression Language, WebSocket, Authentication, Annotations). |
| How often do fixes arrive? | On Red Hat's life cycle. For EAP 8 that is Full Support to 5 February 2028 and Maintenance Support to 5 February 2031. Red Hat provides defect and security fixes only for the latest minor, micro or cumulative-patch release. | With each release. WildFly 41 shipped on 16 July 2026 and 42 on 22 October 2026, so staying current is a routine to build, and AceMQ writes it with you. | With Tomcat releases. Tomcat 9.0 is the last line for Java EE 8, and the Tomcat project expects its end of support no earlier than 31 March 2027. |
| Where can an EAP 7 application run? | On EAP 7 with the ELS add-on: Maintenance Support ended on 30 June 2025, and ELS-1 runs to 31 December 2030 and ELS-2 to 31 December 2031 (Red Hat data, 4 November 2026). | On a WildFly release at the Jakarta EE level the application needs. Moving an EAP 7 application to a Jakarta level means the javax to jakarta change in the application first. | On Tomcat 9.0 if the application uses only the web tier. An application that uses EJB, JMS or JTA needs libraries or a different runtime. |
| Who answers when it fails at 3am? | Red Hat Support, under your subscription terms. | An AceMQ engineer within 15 minutes, 24/7, for diagnosis and operations. | An AceMQ engineer within 15 minutes, 24/7, if you take Tomcat support. |
| Who should stay put? | A team that wants one vendor accountable for the whole stack and has its EAP 8 plan. AceMQ can still run the work beside the subscription. | A team already on WildFly, or one that wants community code and senior engineers on call rather than a subscription. | A team whose applications do not use the full platform. AceMQ is not the right partner for a team that only wants applications rewritten. |
Lifecycle dates for other Java runtimes are in Java LTS versions and end-of-life dates by vendor. AceMQ is an independent provider: it sells no Red Hat subscription and gives no Red Hat licensing advice.
One partner, not five
JBoss 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 Java lifecycles and support options, plus the AceMQ services around the server: Tomcat, Spring Boot, the JDK and Kubernetes.
FAQs
Five answers on JBoss and WildFly from AceMQ: who supports WildFly, what EAP 8 changes, the Red Hat question and what AceMQ does not sell.
Still have questions about JBoss? Email an Expert
WildFly is a community project sponsored by the Commonhaus Foundation, and the project's about page says nothing about commercial support. Red Hat sells the supported product, JBoss EAP. AceMQ supplies the engineers who run WildFly in production: diagnosis, tuning, upgrades and 24/7 on-call. A defect in WildFly's own code goes to the project, because AceMQ does not produce WildFly builds.
Red Hat's guide names the javax.* to jakarta.* package rename, part of the move to Jakarta EE 10, as the biggest change. It also lists removals such as OSGi support, the PicketLink subsystem, the legacy security subsystem and security realms. EAP 8 reached general availability on 5 February 2024, with Full Support to 5 February 2028 and Maintenance Support to 5 February 2031 on Red Hat's data. AceMQ plans the server side and lists the application changes for your developers.
That is a question for Red Hat and your own counsel, because AceMQ is an independent provider and gives no Red Hat licensing advice. EAP is Red Hat's product and its patches come from Red Hat under a subscription, so AceMQ produces none. For security patches on software past its vendor's support, see OSSeva at osseva.io. AceMQ works beside whatever you hold.
Yes. AceMQ works on JBoss 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 JBoss 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 JBoss 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 what you run, tells you what to inventory first, and quotes the work. Quote requests are answered within 1 hour.
Production incident right now?Email a JBoss 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.
