apache
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 无法更新问题，是否有解决思路或方案？
After provider shutdown, the data will be pushed to consumer and HeaderExchangeClient and LazyConnectExchangeClient should be destroyed.
After provider shutdown, the data will be pushed to consumer and
HeaderExchangeClientandLazyConnectExchangeClientshould be destroyed.
从代码看，consumer端的 DubboProtocol#referenceClientMap 会缓存历史的 ReferenceCountExchangeClient。 只有 DubboProtocol.destroy() 才会清理历史缓存对象，但这个对象只有系统关闭才会调用。 HeaderExchangeClient and LazyConnectExchangeClient destroy 不会清理 缓存。故导致provider启动后后，consumer 获取缓存中的client 是 lazy模式，且url 参数都是历史缓存的。
