Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

[Bug] File descriptor leak in CLI CSV import: CSVParser from readCsvFile is never closed

未關閉
#18,237 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

@PDGGK 已經在處理了。

開始於 2026年7月18日。

  • #18238 來自 @PDGGK —— 未關閉

評估

難度
3/5
預估耗時
1-2 天
新手友好度
76/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
冷清
技術堆疊
java
領域
cli

研究方向

先閱讀 AbstractDataTool.readCsvFile 以及指定的匯入進入點:ImportData.importFromSingleFile、ImportDataTree.importFromCsvFile、ImportDataTable.importFromCsvFile 和 ImportSchemaTree.importSchemaFromCsvFile。在較低的 ulimit 下使用許多小型 CSV 檔案重現問題,接著確認每個剖析器在正常完成和提前 return 時都會關閉,而不會耗盡檔案描述元。

由索引模型根據 Issue 內容生成。

描述

Search before asking
  • I searched in the issues and found nothing similar.
Version

master (2.0.x). The affected code is also present in released 2.0.x versions.

Describe the bug and provide the minimal reproduce step

AbstractDataTool.readCsvFile(String) builds a CSVParser over new InputStreamReader(new FileInputStream(path)) and returns it. The CSVParser owns that FileInputStream, but the CLI import code paths that call it never close the returned parser — it is assigned to a local inside a plain try { ... } block (no try-with-resources, no finally). Every imported file therefore leaks its file descriptor, and the early returns for an empty file or an invalid header leak it immediately, because the parser is opened before those checks run.

Affected call sites (current master, also present in released 2.0.x):

  • iotdb-client/cli/src/main/java/org/apache/iotdb/tool/data/ImportData.java — importFromSingleFile
  • iotdb-client/cli/src/main/java/org/apache/iotdb/tool/data/ImportDataTree.java — importFromCsvFile
  • iotdb-client/cli/src/main/java/org/apache/iotdb/tool/data/ImportDataTable.java — importFromCsvFile
  • iotdb-client/cli/src/main/java/org/apache/iotdb/tool/schema/ImportSchemaTree.java — importSchemaFromCsvFile (this class has its own copy of readCsvFile)

Minimal reproduce step:

  1. Create a directory containing a large number of small CSV files — more than the process open-file limit (for example a few thousand files under ulimit -n 1024).
  2. Run the CLI data import over that directory.
  3. The import fails partway through with Too many open files. (A single import already leaks one descriptor; it is simply not fatal until enough accumulate.)
What did you expect to see?

Each CSVParser (and the FileInputStream it wraps) is closed after the file is processed, on every exit path — including the empty-file / invalid-header early returns. Importing a large directory of CSV files should not exhaust the process's file descriptors.

What did you see instead?

The CSVParser returned by readCsvFile is never closed, so its underlying FileInputStream stays open. Importing a directory with enough CSV files leaks descriptors until the import fails with Too many open files.

Anything else?

The record Stream is fully consumed inside the same block before the method returns, so consuming each parser in a try-with-resources (closing it on scope exit) is safe.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
主要語言
Java
星號
6.4k
分支
1.2k
平均合併
1 天 11 小時
30 天內合併 PR
182

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

apache/iotdb 的其他 Issue

查看 apache/iotdb 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。