RestTemplate 设置每个请求的超时时间

本文介绍了RestTemplate 设置每个请求的超时时间的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个带有多个方法的 @Service，每个方法使用不同的 Web api.每个调用都应该有一个自定义的读取超时.拥有一个 RestTemplate 实例并在每个方法中通过工厂更改超时是否是线程安全的

I have a @Service with several methods, each method consumes a different web api. Each call should have a custom read timeout. Is it thread-safe to have one RestTemplate instance and change the timeout via the factory in each method like so

((HttpComponentsClientHttpRequestFactory)restTemplate.getRequestFactory()) .setReadTimeout(customMillis);

我担心的是我正在更改工厂的超时时间，它不像 RequestConfig.考虑到这些方法可能同时被多个用户调用，这种方法是否是线程安全的?或者每个方法都应该有自己的RestTemplate?

My concern is that I'm changing the timeout on the factory and its not like a RequestConfig. Will this approach be thread-safe considering these methods might get called by multiple users at the same time? Or each method should have its own RestTemplate?

推荐答案

在 RestTemplate 初始化后更改工厂超时只是一个等待发生的竞争条件(如 Todd 解释).RestTemplate 真正设计为使用预配置的超时构建，并且这些超时在初始化后保持不变.如果您使用 Apache HttpClient 那么是的，您可以为每个请求设置一个 RequestConfig，我认为这是正确的设计.

Changing timeouts from the factory after RestTemplate initialization is just a race condition waiting to occur (Like Todd explained). RestTemplate was really designed to be built with pre-configured timeouts and for those timeouts to stay untouched after initialization. If you use Apache HttpClient then yes you can set a RequestConfig per request and that is the proper design in my opinion.

我们已经在我们的项目中到处使用了 RestTemplate 并且我们目前无法真正负担重构，这会导致 http 客户端切换.

We are already using RestTemplate everywhere in our project and we can't really afford the refactoring at the moment, that an http client switch would ensue.

现在我最终得到了一个 RestTemplate 池化解决方案，我创建了一个名为 RestTemplateManager 的类，并赋予它创建模板和池化它们的全部责任.这个管理器有一个按服务和 readTimeout 分组的本地模板缓存.想象一个具有以下结构的缓存哈希图:

For now I ended up with a RestTemplate pooling solution, I created a class called RestTemplateManager and I gave it all responsibility of creating templates and pooling them. This manager have a local cache of templates grouped by service and readTimeout. Imagine a cache hashmap with the following structure:

服务A|1000 ->休息模板

ServiceA|1000 -> RestTemplate

服务A|3000 ->休息模板

ServiceA|3000 -> RestTemplate

服务B|1000 ->休息模板

ServiceB|1000 -> RestTemplate

key 中的数字是以毫秒为单位的 readTimeout(key 可以调整以支持更多的 readTimeout 以后).所以当ServiceA请求一个1000ms读超时的模板时，管理器会返回缓存的实例，如果不存在就会创建并返回.

The number in the key is the readTimeout in milliseconds (key can be adapted to support more than readTimeout later on). So when ServiceA requests a template with 1000ms read timeout, the manager will return the cached instance, if it doesn't exist it will be created and returned.

在这种方法中，我避免了预先定义 RestTemplates，我只需要从上面的经理那里请求一个 RestTemplate.这也将初始化保持在最低限度.

In this approach I saved myself from pre-defining RestTemplates, I only have to request a RestTemplate from the manager above. This also keeps initializations at a minimum.

直到我有时间放弃 RestTemplate 并使用更合适的解决方案为止.

This shall do until I have the time to ditch RestTemplate and use a more appropriate solution.