Timeout after provider restart

Problem Description:
(1) If the consumer is not configured in lazy mode, use the HeaderExchangeClient object, that is, the consumer directly establishes a connection with the provider during the release restart phase.
(2) After the provider stops, the client on the consumer side is replaced by LazyConnectExchangeClient (ReferenceCountExchangeClient#replaceWithLazyClient logic)
(3) After the provider is restarted, the isClosed logic of LazyConnectExchangeClient returns false by default when client == null; causing the consumer to be unable to create a new client object and instead use the lazy object in the DubboProtocol#referenceClientMap cache to communicate with the provider;
(4) Problem: This object will not automatically establish a connection. It will not establish a connection with the provider until the first request, resulting in an increase in overall time consumption (especially after SSL is turned on) and the risk of request timeout.

Problem summary: The consumer is not configured in lazy mode, but the existing logic causes the provider to restart and the consumer changes to lazy mode, increasing the risk.
In addition: the URL reported in issue=10046 cannot be updated. Is there any solution or solution?

---

问题描述：
（1）如果consumer 没有配置lazy模式，使用HeaderExchangeClient 对象，即consumer 在发布重启阶段 直接与provider建立连接。
（2）provider 停止后，consumer端的 client，被替换为 LazyConnectExchangeClient （ReferenceCountExchangeClient#replaceWithLazyClient逻辑）
（3）provider 重启后，由于LazyConnectExchangeClient 的isClosed逻辑 在client ==null 时，默认返回 false ；导致consumer 无法建立新的 client对象，而是使用DubboProtocol#referenceClientMap缓存中的 lazy对象与provider通信；
（4）问题：此对象不会自动建连，直到第一笔请求才与provider建连，导致整体耗时增加（特别是开启ssl后），有导致请求超时风险。

问题总结：consumer没有配置lazy模式，但现有逻辑导致provider重启，consumer 变为了lazy模式，增加风险。
此外：issue=10046 中反馈的Url 无法更新问题，是否有解决思路或方案？