Loading

Mule Application Experiences Timeouts and Connection Refusals from Upstream Systems Due to HTTP Listener Inbound Connection Accumulation

Publiceringsdatum: Jul 1, 2026
Beskrivning

Your Mule application intermittently stops processing requests from an upstream system (e.g., SAP). The upstream system reports errors such as timeouts, HTTP 504/503, or connection refused. While the Mule application appears to be running normally without internal errors, new inbound requests are not processed. A restart of the application temporarily resolves the issue.

The application logs show no Mule-level errors or warnings during normal operation, because the failures occur at the TCP/NIO layer before the inbound request reaches the Mule flow. Enabling HTTP wire logging (org.mule.service.http.impl.service.HttpMessageLogger at DEBUG) shows the listener responding with a Keep-Alive header and holding connections open after each response.

 

CAUSE
By default, the Mule HTTP Listener keeps inbound TCP connections open after responding (usePersistentConnections defaults to true) so they can be reused for subsequent requests. This is efficient when the client honors keep-alive and reuses the same connection.

The problem arises when the upstream system (e.g., SAP) opens a NEW connection for every request and never reuses the previously opened ones. The old connections are left open longer than they would be reaped, causing them to accumulate over time. Eventually the listener's available connection resources are exhausted, and new inbound connections can no longer be accepted — producing timeouts, HTTP 503/504, or connection-refused errors from the client's perspective.

Because the bottleneck is at the TCP/listener layer (before the Mule flow executes), the application's internal processing appears healthy and no errors are logged. Restarting the application clears all accumulated connections, which is why a restart provides temporary relief.

Lösning

SOLUTION

Choose the option that matches your upstream client's connection behavior.

Option 1 — Reduce the idle connection timeout (less invasive; preferred when some clients DO reuse connections)

Lower connectionIdleTimeout on the http:listener-connection so the listener reaps idle connections sooner than the 40-second default. This preserves connection reuse for well-behaved clients while preventing accumulation from clients that abandon connections. Note: this attribute is only effective while usePersistentConnections is true.

<http:listener-config name="HTTP_Listener_Config" doc:name="HTTP Listener config">
  <http:listener-connection host="0.0.0.0" port="${http.port}"
               connectionIdleTimeout="10000" />
</http:listener-config>

Option 2 — Disable persistent connections (definitive fix when the client never reuses connections)

If the upstream system opens a new connection for every request and never reuses them (as is typical with certain SAP configurations), disable persistent connections. The listener will then close each connection immediately after sending its response, so no idle connections can accumulate.

<http:listener-config name="HTTP_Listener_Config" doc:name="HTTP Listener config">
  <http:listener-connection host="0.0.0.0" port="${http.port}"
               usePersistentConnections="false" />
</http:listener-config>

 

<flow name="your-flow">
  <http:listener config-ref="HTTP_Listener_Config" path="/your-path" doc:name="HTTP Listener"/>
  <!-- Your application logic -->
</flow>

 

IMPORTANT TRADE-OFF: Disabling persistent connections forces a full TCP handshake (and TLS handshake, if HTTPS) on every request. For high-throughput APIs this adds measurable per-request latency and overhead. Only apply Option 2 when the client does not reuse connections — if the client honors keep-alive, prefer Option 1. When usePersistentConnections is set to false, connectionIdleTimeout has no effect, as connections are closed immediately.

 

Steps to apply:

  1. Locate your HTTP Listener configuration (e.g., global.xml or the flow XML where the http:listener-connection is defined).
  2. Add the chosen attribute to the http:listener-connection element.
  3. Redeploy the application to your Mule runtime.
  4. Monitor the application after deployment to confirm inbound connections no longer accumulate and that request latency remains acceptable.

As a general best practice for high-volume applications, also review your worker/replica sizing to ensure adequate resources for peak throughput.

Ytterligare resurser

APPLIES TO

  • Mule Runtime 4.x
  • HTTP Connector (all versions) — applies to any listener, including those fronting SOAP/Web Service Consumer inbound endpoints
  • All deployment targets: CloudHub 1.0, CloudHub 2.0, Runtime Fabric, and On-Premises (customer-hosted). The behavior is a property of the Mule HTTP Listener and is not specific to any single deployment target.
Knowledge-artikelnummer

005388238

 
Laddar
Salesforce Help | Article