ClientHttpRequestFactorySupplier and RestTemplateBuilder use to instantiate a ClientHttpRequestFactory.

However, i noticed that https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.java is a ClientHttpRequestFactory but is also a DisposableBean that is supposed to close the underlying httpClient.

I may be wrong but this means that if we use ClientHttpRequestFactorySupplier or RestTemplateBuilder in conjunction with HttpComponentsClientHttpRequestFactory class, we may have a resource leak there.

Using Spring Boot 2.2.9 RELEASE, Spring Web 5.2.8 RELEASE

Comment From: bclozel

The Spring Boot team discussed this issue, and we feel like we'd like some guidance from the Framework team about component lifecycle and responsibilities with RestTemplate and RequestFactory.

Where should these resources should be cleaned up and how?

Comment From: rstoyanchev

HttpComponentsClientHttpRequestFactory was created as a DisposableBean from the very start in 3.1. I think this indicates the intent is for the factory to be declared as a bean in which case it can clean up. This part makes sense, however the factory also accepts an HttpClient and assumes responsibility to shut it down even though that was created externally. By comparison Netty4ClientHttpRequestFactory and OkHttp3ClientHttpRequestFactory also implement DisposableBean and also accept externally configured resources but they do differentiate between an internally created and an externally created and managed instance.

I believe having the factory as a Disposable bean and performing clean up makes sense. One issue is that HttpComponentsClientHttpRequestFactory currently does not differentiate between internally and externally managed client lifecyle. Also from a present day perspective ideally we would separate the case of customizing client or resource properties (e.g. via a Consumer for a client builder) vs allowing external control of its lifecycle which I imagine is a lot less common.

Comment From: bclozel

The Spring Framework team just discussed this issue.

When it comes to RestTemplate usage, common patterns involve: a Spring Boot application injecting a RestTemplateBuilder bean in a component constructor, possibly calling methods on it and creating a RestTemplate from it. This RestTemplate instance is stored in a class attribute.

  • as a result, ClientHttpRequestFactory implementations are not declared as beans. Some Spring Framework implementations implement DisposableBean which doesn't really fit this case. We could make them implement AutoCloseable as well.
  • the piece code instantiating the request factory should be in charge of closing resources properly
  • this doesn't apply 1:1 to the reactive case with WebClient, as there we've introduced specific types for this, such as JettyResourceFactory and ReactorResourceFactory

With that in mind, we would need to consider how to apply this to Spring Boot.

Comment From: bclozel

Closing in favor of spring-projects/spring-framework#29010, a new Spring Boot issue should be created in case follow-up changes are needed.