Quarkus中为不同Rest Client配置不同超时时间的问题

嘿，我看你遇到的问题是给不同Rest Client配置了不同超时时间，但实际调用时还是触发了30秒的默认超时对吧？这问题我之前也碰到过，咱们一步步来解决：

首先得说清楚问题根源：你在调用代码里手动加了 .await().atMost(Duration.ofMillis(TIMEOUT_LIMIT_MILLISECOND)) 这个30秒的超时限制，这会直接覆盖你在配置文件里给Rest Client设置的超时时间！不管你在quarkus.rest-client.core-api.read-timeout里写了1小时，代码里的这个手动超时会先触发，导致你看到的30秒超时现象。

接下来给你两个可行的解决方案：

方案一：移除手动的await超时，让配置文件的设置生效 #

Quarkus的Rest Client本身已经会根据你配置的read-timeout来控制请求的超时时间了，完全不需要再手动加一层atMost的限制。你只需要把调用代码里的超时部分修改一下：

原来的代码：

serviceVersionApiRestClient.updateServiceVersion(serviceId, versionNumber, serviceVersionUpdateDto)
    .onFailure(this::isCauseInEnum)
    .transform(WorkflowVersionRestException::new)
    .map(workflowVersionApiRestMapper::toModel)
    .await().atMost(Duration.ofMillis(TIMEOUT_LIMIT_MILLISECOND));

修改后：

serviceVersionApiRestClient.updateServiceVersion(serviceId, versionNumber, serviceVersionUpdateDto)
    .onFailure(this::isCauseInEnum)
    .transform(WorkflowVersionRestException::new)
    .map(workflowVersionApiRestMapper::toModel)
    .await();

这样修改后，Rest Client就会严格遵循你配置文件里quarkus.rest-client.core-api.read-timeout=3600000的1小时超时设置了。

方案二：如果必须保留await超时，让它和配置值保持一致 #

如果你因为某些业务原因，一定要保留await().atMost(...)的写法，那可以把配置文件里的超时值注入到代码中，而不是用硬编码的TIMEOUT_LIMIT_MILLISECOND：

1. 首先在你的类里注入对应Rest Client的超时配置：

@ConfigProperty(name = "quarkus.rest-client.core-api.read-timeout")
long coreApiReadTimeout;

2. 然后在调用时用这个注入的值：

serviceVersionApiRestClient.updateServiceVersion(serviceId, versionNumber, serviceVersionUpdateDto)
    .onFailure(this::isCauseInEnum)
    .transform(WorkflowVersionRestException::new)
    .map(workflowVersionApiRestMapper::toModel)
    .await().atMost(Duration.ofMillis(coreApiReadTimeout));

这样既保留了await的超时写法，又能和配置文件里的设置保持一致，不会出现冲突。

最后再做两个小验证 #

1. 检查@RegisterRestClient(configKey = "core-api")里的configKey和配置文件里的quarkus.rest-client.core-api.read-timeout的core-api是否完全一致（虽然Quarkus配置大小写不敏感，但最好保持拼写完全一致避免坑）。
2. 确认你用的是Reactive Rest Client（从代码里的Uni可以看出来是对的），对应的配置项确实是read-timeout，这个配置是专门控制Reactive Rest Client请求超时的。

按上面的方法调整后，应该就能正常触发你配置的不同超时时间了！

内容来源于stack exchange