[Feature request] CLI should support automatic reconnection when connection is lost during interactive session
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
- #17181 von @miantalha45 — ohne Merge geschlossen
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
Rechercherichtung
Beginnen Sie in iotdb-client/cli/src/main/java/org/apache/iotdb/cli/Cli.java, insbesondere mit receiveCommands() und processCommand, und lesen Sie anschließend IoTDBConnection.reconnect() und IoTDBStatement.callWithRetryAndReconnect() unter iotdb-client/jdbc. Die Aufgabe ist abgeschlossen, wenn verbindungsbezogene Fehler mit einer begrenzten Anzahl von Wiederverbindungsversuchen erneut versucht werden, eine erfolgreiche Wiederherstellung den Befehl mit Feedback erneut ausführt und eine fehlgeschlagene Wiederherstellung eindeutig beendet.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Search before asking
- I searched in the issues and found nothing similar.
Motivation
I am always frustrated when the IoTDB CLI exits as soon as the connection to the server is lost (e.g. server restart, network blip, or idle timeout). I have to reconnect manually, re-enter connection parameters, and lose my session context.
Other IoTDB clients already support reconnection: the Session API (Java), JDBC (via callWithRetryAndReconnect in IoTDBStatement), and the C++/Python clients all retry and reconnect on connection failure. The CLI is the only major client that does not—it holds a single connection for the entire interactive session and exits on any connection-related error. Adding automatic reconnection to the CLI would align its behaviour with the rest of the client stack and improve the experience for long-lived interactive sessions (e.g. over SSH or after server restarts).
Solution
Proposed behaviour
-
Detect connection loss
When a command fails with a connection-related error (e.g. SQLException caused by connection refused, timeout, or closed connection), do not exit immediately. -
Attempt reconnection
Try to establish a new connection using the same parameters (host, port, user, password, and options) that were used at login. Reuse the same logic as the initial connection (e.g. DriverManager.getConnection with the same URL and properties). -
Retry the command
After a successful reconnection, retry the same user command (the current line/statement that failed) with the new connection, with a bounded number of retries (e.g. 3) and optional backoff. -
User feedback
On successful reconnection, print a short message such as: "Connection lost. Reconnected. Retrying command." and continue the interactive loop with the new connection. -
Failure handling
If reconnection fails after all retries, exit with a clear error message, e.g. "Could not reconnect after N attempts. Please check that the server is running and try again."
Relevant code
-
iotdb-client/cli/src/main/java/org/apache/iotdb/cli/Cli.java:receiveCommands()opens one connection and runs awhile (true)loop; any SQLException is caught at the top level and the process exits (lines 215–217).- Change: catch connection-related failures inside the loop (or around
processCommand), attempt reconnection, then retry the command or continue with the new connection.
-
iotdb-client/jdbc:IoTDBConnection.reconnect()andIoTDBStatement.callWithRetryAndReconnect()can be used as reference for retry/reconnect behaviour.
Optional
- Make retry count and interval configurable (e.g. CLI options or environment variables) for consistency with Session/JDBC.
Alternatives
-
No retry, only reconnect
On connection loss, attempt reconnection and, on success, continue the session without retrying the failed command (user re-enters it). Simpler to implement but less convenient than retrying the last command. -
Prompt user
On connection loss, prompt: "Connection lost. Reconnect? (y/n)". If yes, reconnect and optionally retry the command. Gives control but adds friction for automated or scripted use. -
Leave as-is
Keep current behaviour (exit on connection loss). This preserves simplicity but leaves the CLI as the only client without reconnection support and worsens UX for long sessions and unstable networks.
Are you willing to submit a PR?
- I'm willing to submit a PR!
- Vorherrschende Sprache
- Java
- Sterne
- 6.4k
- Forks
- 1.2k
- Ø Merge
- 1 T. 11 Std.
- Gemergte PRs (30 T.)
- 182
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/iotdb
-
[Bug] sbin/replace-conf-from-env.sh word-splits the whole environment and corrupts iotdb-system.propertiesEvtl. vergeben @anishmehta24 hat das vor 30 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
apache/iotdb#18655 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
IoTDB Edge: stop-edge.sh does not stop its own process when IOTDB_HOME is set, and reports successEvtl. vergeben @PDGGK hat das vor 49 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
[Bug] findColumn throws NullPointerException instead of SQLException for an unknown column nameEvtl. vergeben @PDGGK hat das vor 91 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
[Bug] ResultSetMetaData.getCatalogName throws IndexOutOfBoundsException instead of SQLException for out-of-range columnsEvtl. vergeben @PDGGK hat das vor 93 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
Maintainer antworten meist innerhalb von 1 Tag
-
[Bug] dubbo.protocol.triple.max-message-size is only read from OS environment variablesEvtl. vergeben @CCCLL hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
youngyangyang04/leetcode-master#3026 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
hierynomus/sshj#1070 ·
-
Typo in ExecutorTemplate.cacelAllFuturesEvtl. vergeben @xgx2025 hat das heute übernommen. Offen
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 82/100