Mule 4.11 HTTP Listener worker thread parked indefinitely on multipart/form-data upload after upgrade from Mule 4.9

After upgrading a Mule application from runtime 4.9 to 4.10 or 4.11, flows that handle multipart/form-data uploads may have HTTP worker threads parked for hours or days when an HTTP client disconnects mid-upload. The thread dump shows the worker stuck inside MimeMultipart.parse / readFully, called from a DataWeave expression that reads payload.parts before the main flow processing.

The behaviour change is caused by Mule 4.10/4.11 switching the default HTTP service implementation from Grizzly (which buffered the request body up-front) to Netty (which streams it lazily on demand). Combined with the HTTP Listener not enforcing a read timeout while the body is still being received, a single dropped client connection can permanently leak a worker thread.

This article describes the symptoms, the diagnostic stack signature, the immediate workaround, and the permanent application-level fix.

Symptoms

- One or more HTTP Listener flows that consume multipart/form-data stop responding on a specific endpoint after the runtime is upgraded from 4.9.x to 4.10.x or 4.11.x.
- Over time the [MuleRuntime].uber.* worker pool grows; eventually the application becomes unresponsive on the affected endpoint.
- The same flow code worked correctly on Mule 4.9.
- A thread dump shows one or more workers stuck on the following stack (the thread name will reference the affected endpoint, for example "post:\<path>:multipart\form-data:<config>"):

      java.lang.Thread.State: RUNNABLE
          at sun.nio.ch.EPoll.wait(...)
          ... (Netty I/O frames) ...
          at o.m.r.a.h.utils.BlockingBidirectionalStream.read(...)
          at o.m.r.a.h.s.fileStore.FileStoreInputStreamBuffer.consumeForwardData(...)
          at jakarta.mail.internet.MimeMultipart.readFully(...)
          at jakarta.mail.internet.MimeMultipart.parse(...)
          at jakarta.mail.internet.MimeMultipart.getCount(...)
          at o.m.weave.v2.module.multipart.MultiPartReader.doRead(...)
          at o.m.weave.v2.runtime.WeaveExpressionLanguageSession.evaluate(...)
          at o.m.r.c.e.el.dataweave.DataWeaveExpressionLanguageAdaptor$1.evaluate(...)
          at o.m.r.c.i.p.simple.AddFlowVariableProcessor.process(...)

- The runtime log may also contain repeated cosmetic ERROR entries with the prefix "ForwardingToListenerHandlerReplica" and message "Connection reset". This is a separate, harmless log-noise issue that shares the same workaround.

Environment

- Mule Runtime 4.10.x or 4.11.x (verified on 4.11.4 / JDK 17.0.15)
- Default HTTP service implementation Netty (org.mule.service.http.netty)
- Application uses an HTTP Listener configured with multipart/form-data
- The flow reads payload.parts (or payload.parts.<name>.content) in a processor placed before the main transformation, for example inside a <set-variable />, <logger />, or preliminary <ee:transform />.

Root Cause
In Mule 4.9 the HTTP service was Grizzly. Grizzly buffered the entire multipart body up-front, so any DataWeave expression that referenced payload.parts found the body already materialised and returned immediately.

In Mule 4.10/4.11 the HTTP service is Netty (default). Netty streamsthe request body lazily — bytes are pulled from the socket only when the flow actually reads the payload. When the flow accesses payload.parts early (for example via "<set-variable value="#[payload.parts.binary.content]"/>"), the DataWeave evaluator calls MimeMultipart.parse() -> readFully(), which forces the entire body to be drained from the socket synchronously on the application worker thread.
 
If the HTTP client disconnects mid-upload (network blip, client abort, idle keep-alive timeout, slow client), the worker remains parked in BlockingBidirectionalStream.read waiting for bytes that never arrive. The Mule 4.11 HTTP Listener does not enforce a read timeout while the request body is being received, so the worker is never reclaimed. Repeated occurrences leak workers permanently from the runtime pool.

Reading payload.parts more than once in the same flow (for example once in <set-variable /> and again inside <ee:transform />) amplifies the impact because each access can re-trigger materialisation.