[CI] NettyClientTest.testServerDisconnection may fail with DisconnectException
メンテナーはふだん 1 日以内に返信
評価
調査の方向性
165行目の失敗するアサーション付近にある NettyClientTest.testServerDisconnection から始めます。リクエスト失敗後に接続マップが空になるまでテストがどのように待機するかを読み、その後、既存のクリーンアップ待機を維持しながら、nettyServer.close() の後、次のリクエストの前に待機を追加します。対象のテストを繰り返し実行し、常に ConnectException をアサートすることを確認します。
索引モデルが issue の本文から書いたものです。
説明
Search before asking
- I searched in the issues and found nothing similar.
Fluss version
1.0.0 (latest release)
Please describe the bug 🐞
NettyClientTest.testServerDisconnection can still fail intermittently in CI after #4344.
The test expects a ConnectException when sending a request after shutting down the Netty server, but occasionally receives a DisconnectException instead:
NettyClientTest.testServerDisconnection:165
Expecting actual throwable to be an instance of:
java.net.ConnectException
but was:
org.apache.fluss.exception.DisconnectException:
Cannot send request to server localhost:40463
(id: cs-1, rack: null) because it is disconnected.
https://github.com/apache/fluss/actions/runs/39053988878/job/117458107688?pr=4545
After nettyServer.close(), the client detects the disconnection and asynchronously removes the old ServerConnection from its connection map.
However, the test immediately sends another request without waiting for the old connection to be removed.
If the request arrives after the connection has entered the DISCONNECTED state but before it is removed from the map, NettyClient.getOrCreateConnection() may return the disconnected connection.
In this case, ServerConnection.doSend() fails the request with a DisconnectException rather than attempting a new connection that would fail with a ConnectException.
This makes the exception assertion sensitive to the timing of asynchronous connection cleanup.
The previous fix in #4344 added a retry to wait for the connection map to become empty, but that retry happens after the failed request and therefore does not prevent this race.
Solution
Wait for the old connection to be removed after shutting down the server and before sending the next request.
Keep the existing retry after the failed request to ensure that the newly created, failed connection is also cleaned up before restarting the server.
This preserves the existing ConnectException assertion and requires no changes to production code.
Are you willing to submit a PR?
- I'm willing to submit a PR!
- 主要言語
- Java
- スター
- 2.2k
- フォーク
- 658
- 平均マージ
- 2日 23時間
- マージ済み PR（30日）
- 103
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/fluss のほかの issue
-
[lake/iceberg] Reserved write-mode properties can be set and reset through their `iceberg.` key対応中かも @aphenix-r7 が 10 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
apache/fluss#4658 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[common] Decimal#hashCode is inconsistent with Decimal#equals対応中かも @firasbouzazi が 21 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/fluss#4538 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[security] PlainSaslServerProvider conflicts with Hadoop SASL provider causing authentication failure対応中かも @xinzhang-hello が 27 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
[server] KV snapshot scheduling stops permanently after a transient snapshot-init failure対応中かも @zhang-arvin が 27 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
apache/fluss#4489 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[docs] Document advertised-resource and ACL principal ignore-case options対応中かも @EchoLee5 が 39 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
521xueweihan/HelloGitHub#4105 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
code-maintenance
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
krizaka/krizaka-notifications#32 ·
メンテナーはふだん 1 日以内に返信