Connection/Read Timeouts with Load Balanced Rest Template

We are migrating our load balanced RestTemplates from using the legacy, netflix http client to the new RestTemplate + Spring Retry.

One thing that surprised us was that the ribbon setting for connection timeouts are NOT applied when using the rest template. This actually seems like an obvious fact once you think about it, but it means that timeouts for the load balanced rest templates really need to be configured differently then how you configure those same timeouts in zuul (and likely Feign).

The connection/read timeouts for a load balanced rest template are NOT configured via the ribbon properties. Instead, you must set your timeouts when constructing the rest template via setConnectionTimeout and setReadTimeout in the restTemplateBuilder.

We ended up normalizing our code such that it just injects those same ribbon timeouts settings into our template:

	@Value("${ribbon.ConnectionTimeout:1000}")
	int connectionTimeout;

	@Value("${ribbon.ReadTimeout:20000}")
	int readTimeout;

	@Bean
	@LoadBalanced
	public RestTemplate buildRestTemplateRibbon(RestTemplateBuilder restTemplateBuilder) {
		return restTemplateBuilder.messageConverters(new BuildHttpMessageConverters().getConverters())
			.uriTemplateHandler(new BuildUriTemplateHandler())
			.setConnectTimeout(connectionTimeout)
			.setReadTimeout(readTimeout)
			.errorHandler(new ServiceClientErrorHandler()).build();
	}

It would be nice if that were the default behavior in spring cloud, as then the timeouts are set the same across zuul, feign, and the load balanced rest template.

Or alternatively, it might be good to make a note in the documentation: If you are using the load balanced rest template with retry, you need to explicitly set your read/connection timeouts when constructing the template.

Start by reviewing the load-balanced RestTemplate setup and the RestTemplateBuilder calls described in the issue. Trace how Ribbon timeout properties relate to Spring Retry and the Zuul and Feign configurations. Done should be either consistent timeout behavior by default or a documentation note explaining the required explicit configuration.