dubbo
dubbo copied to clipboard
apache
retries设置问题
- [ ] I have searched the issues of this repository and believe that this is not a duplicate.
Environment
- Dubbo version: 3.1.0
- Operating System version: centos 7.9、windows10
- Java version: 8、11
Steps to reproduce this issue
1.application.yaml配置如下：
提供者服务配置
provider: # 默认快速失败 cluster: failfast # 不进行重试 retries: 0 消费者调用超时，没有进行快速失败，并且进行了重试三次 2.@DubboService(cluster = "failfast",methods = {@Method(name = "test", retries = 0)}) 即使在提供者针对方法级别进行配置，还是和第一个问题产生的结果一致
retry 是一个客户端行为，不会受服务端的配置所影响。
背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。
您说的在consumer配置负载和retries应该是进入dubbo3之后才开始调整的吧？我之前一直用的2.7+版本一直是在provider中配置的cluster和retries完全没有问题。 如果provider不建议配置的话，应当尽早将属性@Deprecated话。
retry 是一个客户端行为，不会受服务端的配置所影响。
背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。
retry 是一个客户端行为，不会受服务端的配置所影响。
背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。
还有一个点，我这边在provider配置timeout经过测试是有效的，consumer没有进行配置。 那么基于您阐述的这个思路，如果一个服务端timeout设置为10秒，一个设置为20秒，那客户端怎么生效
timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的
timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。
timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的
timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。
谢谢，收获良多
timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的 timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。
谢谢，收获良多
大佬，那你后面是如何解决重复调用这个问题？
timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的
timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。
@DubboReference(cluster = "failfast", retries = 0) 我是在消费端这么去配置的，可是当服务超时，还是会触发重复调用
timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的 timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。
@DubboReference(cluster = "failfast", retries = 0) 我是在消费端这么去配置的，可是当服务超时，还是会触发重复调用
用的什么版本，我测试的话都是没问题的
retry 是一个客户端行为，不会受服务端的配置所影响。
背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。
这个不是很好解决吗？客户端配置了以客户端的为准，客户端没有配置以服务端为准
