Mule Application Experiences a Connection Timeout After TCP Handshake When Using Streaming

Symptom

A connection timeout error occurs when attempting to make an outbound request (e.g., via an HTTP Requestor) from a Mule application. This error can manifest in several ways:

• A remote server-side error, such as Remotely closed.
• A local connector error, such as java.net.ConnectException: Connect timeout.

The underlying behavior observed at the network level is that the three-way TCP handshake completes successfully, but the client application (Mule) fails to send the next expected data packet, such as the ClientHello to initiate the TLS handshake. Due to this delay, the remote server or an intermediary network device closes the idle connection, resulting in a timeout.

This issue is most common when processing large payloads.

Cause

The primary cause of this delay is the use of deferred execution in a DataWeave transformation (deferred=true) immediately before the connector making the network call (e.g., HTTP Requestor).

When deferred=true is used, the execution of the DataWeave script is postponed until the payload is actively consumed by the subsequent component. The process is as follows:

1. The HTTP Requestor component begins its execution and establishes the TCP connection with the target endpoint.
2. Once the connection is established, the Requestor attempts to send the request data (including the TLS handshake, if applicable).
3. At this point, the Requestor requests the payload from the preceding component (the DataWeave transformation).
4. Only then does the DataWeave script begin to execute to generate the payload. If the payload is large or the transformation is complex, this process can take a considerable amount of time.

This latency between the TCP connection establishment and the sending of the first application data bytes can exceed the remote server's timeout threshold, causing it to close the connection prematurely.