> 嗯嗯,忘了这个了,不过你看多个invoker的时候,其实也是会重新选择,一个的时候没有其他选择,所以不判断了吧
嗯呐,但是也有个情况,如果只有一个invoke的时候但不校验isavialable(),这个provider在优雅停机过程中,就不能第一时间发现没有提供者了~最差情况要等
dubbo.service.shutdown.wait 这个时间了。
回到一开始那个问题哈,因为我们对业务成功率要求比较高,出现过这个问题,很偶发。目前改法也在上面说了,但感觉不够优雅~还请指点谢谢
[ Full content available at: https://github.com/apa
> 先关channel也会有问题吧,我先关了,但是registry里还有,这期间你那边也可能会有请求过来
再有多个invoker的时候,doselect()会判断invoker.isavailable()的,通过client.isconnect()和channel状态是否不为readonly,在dubboinvoker这个类
但是单个invoker的时候没这个判断,所以有我上面最后的那个小疑问
[ Full content available at: https://github.com/apache/dubbo/issues/4714 ]
This message was relay
> 也许你可以通过增长`dubbo.service.shutdown.wait`来解决你的问题.优雅关机会等待一段时间(`dubbo.service.shutdown.wait`)以处理已到达的请求然后再关闭channel.
这个时间是用来等待在途交易完成,功能不一样。而且没办法从根本解决这个问题,通过sendreadonly事件可以等价于关闭业务channel, 不会再有业务进入。
目前我是加了一个在registryprotocol加了beforeDestory接口发送事件,但感觉不够优雅
[ Full content available at: https://github.com/