zhangshenghang opened a new pull request, #12684: URL: https://github.com/apache/seatunnel/pull/12684
<!-- Thank you for contributing to SeaTunnel! Please make sure your PR title follows the pattern: [Feature|Fix|Improve][Module] summary. --> ## Purpose of this pull request Fixes #12683 On a multi-node IoTDB cluster only the leader of a device's data region accepts session writes; every other node replies with TSStatus **400 (REDIRECTION_RECOMMEND)**. The connector always sent every batch to `node_urls[0]` and retried that same node on failure, so the job died with `StatementExecutionException: 400:` as soon as the first configured node was not the leader — leader failover or load balancing is enough to trigger it. Single-node IoTDB is not affected. ## What changes were proposed in this PR? Only `IoTDBSinkClient` (plus a unit test): - Keep one session per configured node url, created lazily. - **Device → leader cache**: remember which node last accepted each device's writes and group every batch by that node, so steady-state writes go straight to the right leader with zero extra requests. - **Follow 400 immediately, without waiting**: when a node replies REDIRECTION_RECOMMEND, the affected devices are re-routed to the next configured node and retried at once (re-routing is not a retry, so it does not consume the retry budget and does not sleep). - **Mixed batches are split automatically**: a batch containing devices of different regions is rejected as a whole, so those devices temporarily switch to one-device-per-request routing until each has found its leader, then return to normal batched routing. - **Backoff only for network-level failures** (session is rebuilt before the retry); data-level rejections fail fast with the first device and timestamp in the message. - Hard round bound `node count + max_retries + 1` so a leaderless cluster can never spin the loop forever. ## Verifying this change New unit tests in `IoTDBSinkClientTest` (stub nodes that reply 400 like a real follower): - a batch mixing two devices whose leaders are different nodes is split, routed, and written; a second flush goes straight to the leaders and the follower is not contacted again - a data-level rejection (non-400) fails fast after exactly one attempt - a network failure is retried with backoff exactly `node count + max_retries + 1` times before giving up Also verified end-to-end on a 3-node IoTDB 1.3.2 cluster where `node_urls[0]` is a follower of every region: a Kafka → SQL → IoTDB streaming job that previously died on the first batch wrote 600 records across 60 batches, with re-routing only on the first batch, and row counts confirmed in IoTDB. ## Check list - [x] Code changed - [x] Local test: `mvnw -pl seatunnel-connectors-v2/connector-iotdb test` → 43 tests, 0 failures - [x] No public API change (connector-internal behavior only; all existing options keep their meaning) - [x] No documentation change needed (behavior fix) - [x] Compiled and formatted (`spotless:check` passes) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
