What does AceMQ MuleSoft support include?

Our MuleSoft support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, performance and memory tuning, DataWeave optimisation, connector and backend integration work, runtime upgrades, and vCore cost governance. 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.

Why does our Mule app run out of memory on large payloads?

Almost always the streaming strategy. Mule 4's default repeatable in-memory stream keeps the payload in heap once it grows past the initial buffer, and every concurrent request holds its own copy. A single large file is survivable; ten at once is not. Switching to repeatable file-store streaming moves the buffer to disk beyond a threshold, and combining that with a flow design that does not materialise the whole payload — avoiding operations that force the full stream into memory — usually resolves it without increasing worker size.

How is this different from MuleSoft's own support?

MuleSoft supports the Anypoint Platform and the Mule runtime as products. We support the integrations you built on them. Flow design, DataWeave, streaming strategy, connector and pool configuration, worker sizing, error handling, and the backend systems on both ends of your integrations are outside their boundary and inside ours. The two are complementary — we also help you build a clean, evidenced case for their support when an issue genuinely is a product defect.

Can you reduce our vCore consumption and Anypoint costs?

Frequently, yes. The pattern we see most is workers oversized to paper over a memory problem that has a real fix — usually streaming strategy or a DataWeave transformation that materialises a whole collection. Once that is corrected the app runs comfortably at a smaller size. We also look for apps that could be consolidated, non-production environments sized like production, and integrations that no longer serve a purpose. Every recommendation comes with measured evidence rather than a guess.

Our DataWeave transformation is slow. Is that fixable?

Usually, and in the script rather than the runtime. The dominant causes are indexed access inside a map producing quadratic work, repeated lookups against an array where a keyed object would be constant-time, and building large intermediate structures that are immediately discarded. We profile the script against a representative production payload, rewrite the hot path, and verify the output is byte-identical before it ships.

Do you support on-premise Mule runtimes and Runtime Fabric as well as CloudHub?

Yes, all of them, including mixed estates. Runtime Fabric and on-premise deployments hand you the infrastructure layer — resource reservations, readiness probes, node capacity, storage, and networking — which is where a large share of deployment and stability issues actually live. We support that layer alongside the Mule applications rather than treating it as someone else's problem.

How is AceMQ MuleSoft support priced?

Support is priced as an annual contract based on your environment size, required SLA tier, and coverage hours — not per incident or per ticket. That means calling us during an outage never carries a cost decision. Contact us for a quote; we turn them around within 24 hours.

MuleSoft Support

24/7 MuleSoft Support with a 15-Minute Emergency SLA

AceMQ supports the Mule applications and integrations you run — workers restarting under memory pressure from payloads held in memory, DataWeave transformations that fall over at scale, connection pools exhausted against a backend system, VM queues backing up in the process layer, and worker sizing that quietly drives your bill. Every ticket reaches a named senior engineer.

Senior MuleSoft engineers on call right now — 24/7/365

15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Available Now

Book a free Consultation.

Prefer to chat first?

Prefer to E-mail?

info@acemq.com

Trusted for mission-critical MuleSoft by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a MuleSoft outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior MuleSoft engineer. There is no tier-1 triage layer to get through.

P1 — Emergency

15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical

1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High

4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard

Next day

Questions, guidance, best practices, non-urgent improvements

Incident Triage

MuleSoft problems we fix every week

These are real symptoms from real MuleSoft production environments — and the first thing our engineers check when one comes in.

Symptom you're seeingWhat we check firstTypical resolution

Mule app throws OutOfMemoryError on large file or payload processing

What we check firstThe streaming strategy on the source and on every component that consumes the payload. The default in-memory repeatable stream buffers the whole payload once it exceeds the initial buffer, so one large file plus concurrency exhausts heap. Repeatable file-store streaming is usually the fix.

Typical resolution1–2 hours

CloudHub worker restarting repeatedly with no application error

What we check firstWorker memory metrics against heap allocation for the worker size, plus the restart pattern relative to traffic. A worker cycling under memory pressure looks like an application crash in the logs but is a sizing and streaming problem.

Typical resolution1–2 hours

DataWeave transformation takes minutes on a large array

What we check firstWhether the script materialises the whole collection — indexed access inside a map, repeated lookups against an array instead of a keyed object, or a nested map producing quadratic work. We profile the script against a representative payload before changing runtime settings.

Typical resolution2–4 hours

Calls to a backend system time out under load, backend looks idle

What we check firstConnection pool configuration on the connector — max active connections, exhaustion action, and max wait. A pool sized below concurrency makes threads queue for a connection, so the wait happens before the request is ever sent.

Typical resolution1–2 hours

VM queue depth growing in the process layer, messages delayed

What we check firstConsumer concurrency on the VM listener against publish rate, and whether the flow downstream is doing synchronous work it should not. Persistent VM queues absorb the mismatch until they cannot, which is why the symptom appears late.

Typical resolution1–3 hours

Deployment to Runtime Fabric fails or the app never becomes ready

What we check firstRequested CPU and memory reservations against the available capacity on the fabric, then the readiness probe behaviour. Resource limits that cannot be satisfied leave the deployment pending with little in the application log.

Typical resolution1–3 hours

Messages processed twice after a worker restart or redeploy

What we check firstTransaction boundaries and acknowledgement mode on the source connector. Where a JMS or Anypoint MQ listener acknowledges before the flow completes, a restart mid-flow loses the work and the redelivery reprocesses it.

Typical resolution2–4 hours

API policy applied in API Manager is not taking effect

What we check firstWhether the autodiscovery configuration in the app matches the API instance ID and environment. A mismatch leaves the app running unpoliced while API Manager shows the policy as applied.

Typical resolutionSame day

Resolution times reflect typical MuleSoft engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking

Support In Practice

MuleSoft problems we've already solved

Representative engagements showing how these incidents get diagnosed and closed under an AceMQ support contract.

All use cases

Remediation

MuleSoft Streaming Strategy and OOM Remediation

Wholesale Distribution Group

Resolving out-of-memory failures in a Mule application that buffered entire multi-hundred-megabyte payloads because no repeatable streaming strategy was configured.

MuleSoftKubernetesDocker

Read case study

Support

MuleSoft CloudHub Worker Restart and Memory Pressure Support

Specialty Retail Chain

Investigating recurring CloudHub worker restarts under memory pressure and the application-level causes behind them.

MuleSoftDockerKubernetes

Read case study

Assessment

MuleSoft Integration Estate Assessment

Regional Healthcare Network

Inventorying and evaluating a MuleSoft estate for reliability, error handling, and reuse before committing to either investment or migration.

MuleSoftRabbitMQPostgreSQL

Read case study

What's Included

Everything in your MuleSoft support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency Incident Response

Workers restarting, integrations stalled, queues backing up, or a deployment that will not come healthy. A senior engineer joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.

vCore & Worker Cost Governance

Worker sizing against measured heap and throughput, consolidating over-provisioned apps, and identifying integrations whose vCore consumption is driven by a fixable memory or streaming problem rather than real load.

Performance & Memory Tuning

Streaming strategy selection, DataWeave profiling and rewrite, connection pool sizing, thread and concurrency configuration, and heap analysis against real production payload profiles.

Root Cause Analysis

Every P1 closes with a written RCA: what failed, why, the fix applied, and the flow, connector, or runtime change that prevents recurrence. Delivered as standard, not on request.

Connectors & Backend Integration

JMS, Anypoint MQ, database, SAP, Salesforce, and HTTP connectors configured for the delivery semantics, retry behaviour, and error handling your integrations actually need under failure.

Upgrades & Deployment Models

Mule runtime upgrades, migration between CloudHub, CloudHub 2.0, Runtime Fabric, and on-premise runtimes, and moving integrations off MuleSoft entirely where that is the right commercial call.

Anywhere You Run It

We support MuleSoft wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

CloudHub & CloudHub 2.0Anypoint Runtime FabricOn-premise Mule runtimeMule 4.x runtimesKubernetes & OpenShiftAWS (EC2, EKS)Microsoft Azure (AKS)Google Cloud (GKE)Anypoint MQ & JMS brokersBare metal & on-premiseAir-gapped / restricted egress backendsHybrid cloud

Why AceMQ

What you get that you don't get elsewhere

We Treat vCore Spend as an Engineering Problem

Worker sizing is usually set once, during a project, and never revisited. We measure real heap and throughput, fix the memory behaviour that forced the oversizing, and document the change so the reduction survives the next release.

Named Engineers, Zero Cold Start

The same senior engineers stay on your account. They know your flows, your connectors, and your backend systems — so a P1 call starts with diagnosis, not twenty minutes of you explaining your integration estate.

Deep on the Messaging Behind the Flows

Most Mule incidents are really messaging incidents — acknowledgement modes, transaction boundaries, redelivery, ordering, and queue backpressure. Enterprise messaging is our core discipline, not adjacent knowledge.

No Tier-1 Triage Layer

You reach a senior engineer directly by phone, email, or Slack. No help desk collecting information to pass along, and no escalation approval standing between you and someone who can actually fix it.

We Debug the Layers the Vendor Won't

MuleSoft supports the Anypoint Platform. Your flows, DataWeave, connector configuration, streaming strategy, worker sizing, and the backend systems you integrate are yours — and that is where incidents originate.

Genuine Follow-the-Sun Coverage

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.

FAQ

MuleSoft support questions

When an Integration Stalls, Every System Behind It Waits

Whether you need emergency response tonight or a support contract that keeps workers stable and vCore spend honest, AceMQ staffs every engagement with a named senior engineer. Support quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.