Timeout after provider restart

[fsx379]

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 无法更新问题，是否有解决思路或方案？

[AlbumenJ]

Do you use registry?

[fsx379]

Do you use registry?

yes

[AlbumenJ]

After provider shutdown, the data will be pushed to consumer and HeaderExchangeClient and LazyConnectExchangeClient should be destroyed.

[AlbumenJ]

Please check if you are using the latest version.

[fsx379]

After provider shutdown, the data will be pushed to consumer and HeaderExchangeClient and LazyConnectExchangeClient should be destroyed.

从代码看，consumer端的 DubboProtocol#referenceClientMap 会缓存历史的 ReferenceCountExchangeClient。 只有 DubboProtocol.destroy() 才会清理历史缓存对象，但这个对象只有系统关闭才会调用。 HeaderExchangeClient and LazyConnectExchangeClient destroy 不会清理 缓存。故导致provider启动后后，consumer 获取缓存中的client 是 lazy模式，且url 参数都是历史缓存的。

[LibertyCod]

你用的是哪个版本，2.8.12我也遇到了同样的问题