1

我们一直在看到以下行为，但不确定这是一个已知的错误，还是仅仅是错误配置或滥用库。

  • 使用 curator-framework 2.7.0 Scala 库、zookeeper-3.4.5
  • 在 127.0.0.1:2181 运行连接到本地 zk 服务器的 scala 应用程序。我们已经用不同的重试策略重现了这一点，但为了简单起见，让我们假设我们的重试策略休眠 30 秒并无限期重试。
  • 跟踪 scala 应用程序日志和本地 zk 服务器日志
  • 运行“sudo iptables -A OUTPUT -p tcp --dport 2181 -j DROP”并等待。
  • 最终看到 SUSPENDED 状态更改日志出现在 scala 应用程序日志中。
  • 最终“会话过期”日志出现在 zk 服务器日志上。如果我们现在解除 iptables，scala 应用程序将注册一个 LOST，然后是一个 RECONNECTED。这是我们所期望的。
  • 相反，如果我们在服务器记录 SessionExpiration 之后继续等待而不是立即解除 iptables，我们会在日志中看到 retryPolicy 事件触发并失败。据我所知，仍然是预期的。
  • 问题是如果我们在“很长一段时间”之后提升 iptables，之后会发生几次重试。这里似乎发生的是带有新会话 id 且没有丢失状态更改的 RECONNECTED。最终结果是我们已连接但丢失了所有临时数据并且不尝试重建它，因为此逻辑与 LOST 状态更改相关联。

这似乎与客户端会话 ID“超时”或“清除”有关，以便服务器重新连接假定客户端已经知道会话已过期。对此有任何确认吗？我们目前的想法是在之前和之后缓存​​会话 id 并模拟我们自己的 LOST 状态更改，但这似乎有点像我们在与 api 作斗争。

谢谢

4

1 回答 1

0

Curator 连接状态与标准 ZooKeeper 事件没有直接关系。所以 LOST 并不意味着ZK 会话丢失。这意味着 Curator 根据您的重试设置等认为连接已丢失。请参阅此处的通知部分：http: //curator.apache.org/errors.html

于 2015-06-11T12:33:29.440 回答