我们一直看到以下行为，并且不确定这是一个已知的错误，还是仅仅是错误配置或误用了库。
- 使用curator-framework 2.7.0 Scala库，zookeeper-3.4.5
- 运行连接到127.0.0.1:2181的本地zk服务器的scala应用程序。我们已经使用不同的重试策略重现了这一点，但为了保持简单，我们假设我们的重试策略会休眠30秒并无限期地重试。
- 尾随scala app日志和本地zk服务器日志
- 运行“sudo iptables -A OUTPUT -p tcp --dport 2181 -j DROP”并等待。
- 最终会在scala app log中看到SUSPENDED状态更改日志。
- 最终“会话过期”日志出现在zk服务器日志上。如果我们现在解除iptables，scala应用程序将注册一个LOST，然后是RECONNECTED。这就是我们的期望。
- 如果我们继续等待而不是在服务器记录SessionExpiration之后立即提升iptables，我们会在日志中看到retryPolicy事件并且失败。据我所知，仍然可以预料。
- 问题是如果我们在“很长一段时间”之后解除iptables，之后会发生几次重试。这里似乎发生了一个具有新会话ID的RECONNECTED并且没有LOST状态改变。最终结果是我们已连接但已丢失所有短暂数据，并且不会尝试重建它，因为此逻辑与LOST状态更改有关。
这似乎与客户端会话ID“超时”或“清除”有关，这样服务器重新连接假设客户端已经知道会话已过期。有任何确认吗？我们当前的想法是在之前和之后缓存会话ID并模拟我们自己的LOST状态更改，但这看起来有点像我们正在对抗api。
由于