Use of RequestPart with String leads to a file descriptor leak

[samudra77]

StringHttpMessageConvertor is reading the InputStream but it's not closing it.
This keeps the file handle open and leaks file handles.
I am using @RequestPart in rest controller with string parameter.
the request is a multipart form data. Other Jackson converters are closing the streams.
The stream is pointing to a temporary file created by servlet api on tomcat.

[symphony-youri]

I'm observing this issue too with 2.2.10.RELEASE and more recent versions (up to 2.6.1)

[rstoyanchev]

The behavior goes back to 6661788, and looking at the description in #14728 and #14869, it was related to a server writing with multipart data. However, it was also applied on the reading side too, and it's not clear why, just from reading the linked issues.

One option would be to re-introduce FileCopyUtils on the reading side. Another, to close the InputStream on the server side after reading the body, e.g. in AbstractMessageConverterMethodArgumentResolver. There is a PR along those lines #25897.

[symphony-youri]

As a workaround, moving from @RequestPart to @RequestParam for strings parameters fixes the issue (as the converter won't be used).

[samudra77]

Yes I have changed the code to use request param for string arguments. But wondering if it's also server specific? Noticed this happening with Tomcat after recent patches applied on but couldn't figure out who is the culprit and should be responsible for closing the stream. Someone has to close it. Application code unfortunately has no handle to it.

[symphony-youri]

Interesting, I'm wondering why this issue has been unnoticed in our application. And it has been detected by one user after we (force) upgraded the dependency to tomcat core to 9.0.54 (was 9.0.38 before).

[symphony-youri]

Actually changing to @RequestParam broke some of our API clients that were sending a part with a filename set even though it was a string content. So we had to revert this change.

We are trying another workaround based on a RequestBodyAdvice:

@ControllerAdvice
@Component
public class CloseStringRequestPartAdvice extends RequestBodyAdviceAdapter {
  @Override
  public boolean supports(MethodParameter methodParameter, Type targetType, Class<? extends HttpMessageConverter<?>> converterType) {
    // being extra careful to only apply it for @RequestPart String parameters
    return targetType != null
        && String.class.getTypeName().equals(targetType.getTypeName())
        && converterType.equals(StringHttpMessageConverter.class)
        && methodParameter.getParameterAnnotations() != null
        && methodParameter.getParameterAnnotations().length >= 1
        && RequestPart.class.equals(methodParameter.getParameterAnnotations()[0].annotationType());
  }

  @Override
  public Object afterBodyRead(Object body, HttpInputMessage inputMessage, MethodParameter parameter, Type targetType, Class<? extends HttpMessageConverter<?>> converterType) {
    // extra check, to really be sure we try to close it when needed
    if (supports(parameter, targetType, converterType)) {
      try {
        inputMessage.getBody().close();
      } catch (Exception e) {
        // we rather silently fail than prevent the request from working and eventually leaking a file descriptor
        LOG.debug("Failed to close form data string", e);
      }
    }
    return body;
  }
}

There are extra (and specific to our use case probably) checks done to avoid closing streams inadvertently.