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 状態の変更はありません。最終的な結果として、接続はされていますが、すべての一時データが失われ、このロジックが 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 に答える