> 嗯嗯，忘了这个了，不过你看多个invoker的时候，其实也是会重新选择，一个的时候没有其他选择，所以不判断了吧
嗯呐，但是也有个情况，如果只有一个invoke的时候但不校验isavialable（），这个provider在优雅停机过程中，就不能第一时间发现没有提供者了~最差情况要等
dubbo.service.shutdown.wait 这个时间了。
回到一开始那个问题哈，因为我们对业务成功率要求比较高，出现过这个问题，很偶发。目前改法也在上面说了，但感觉不够优雅~还请指点谢谢
[ Full content available at:
> 先关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
> 也许你可以通过增长`dubbo.service.shutdown.wait`来解决你的问题.优雅关机会等待一段时间（`dubbo.service.shutdown.wait`）以处理已到达的请求然后再关闭channel.
这个时间是用来等待在途交易完成，功能不一样。而且没办法从根本解决这个问题，通过sendreadonly事件可以等价于关闭业务channel， 不会再有业务进入。
目前我是加了一个在registryprotocol加了beforeDestory接口发送事件，但感觉不够优雅
[ Full content available at:
