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

TCP connection not closing properly leading to dangling CLOSE_WAIT state and system overload

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

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
35/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
python, sql

研究方向

使用 Python 3.10.15、databricks-sql-python 3.1.2、所示的 sql.connect 呼叫以及 netstat 重現這兩種情況,以觀察通訊端狀態。當連線在內容管理器或明確的 close 呼叫之後正確關閉、不存在被無限期保留的 CLOSE_WAIT 通訊端,且用戶端資源獲得釋放時,即表示完成。

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

描述

Testcase 1

Python 3.10.15 (main, Sep  7 2024, 18:35:33) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from databricks import sql
>>> sql.__version__
'3.1.2'
>>> with sql.connect(server_hostname = "<HIDE>", http_path = "<HIDE>", access_token = "<HIDE>") as connection:
...     with connection.cursor() as cursor:
...             cursor.execute("select * from table")
...             column_names = [desc[0] for desc in cursor.description]
...             query_out = [dict(zip(column_names, row)) for row in cursor.fetchall()]
...             
... 
<databricks.sql.client.Cursor object at 0x7f88551c14e0>
>>> query_out
[{"sometime" : "something}]


On the sidelines, the network connection for this process (after with clause gets finished), remain in ESTABLISHED state and then moves to CLOSE_WAIT state indefinitely. 

Every 1.0s: netstat -apn | grep 1070099                                                                                          asinha-vm-ubuntu-20-04-1: Wed Nov 20 02:43:13 2024

tcp       25      0 10.5.220.4:58078        so:me:ip:add:443      CLOSE_WAIT  1070099/python3

Testcase 2

Python 3.10.15 (main, Sep  7 2024, 18:35:33) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from databricks import sql
>>> sql.__version__
'3.1.2'
>>> connection = sql.connect(server_hostname = "<HIDE>", http_path = "<HIDE>", access_token = "<HIDE>")
>>> ## at this point a TCP connection got made as ESTABLISHED state ##
>>> cursor = connection.cursor()
>>> cursor.execute("select * from table")
<databricks.sql.client.Cursor object at 0x7f9d65db26b0>
>>> column_names = [desc[0] for desc in cursor.description]
>>> query_out = [dict(zip(column_names, row)) for row in cursor.fetchall()]
>>> cursor.close()
>>> connection.close()
>>> # even after close being called, the connection remains in ESTABLISHED state (for a long time) and then finally moves to CLOSE_WAIT state, which never changes.

Every 1.0s: netstat -apn | grep 1074808                                                                                          asinha-vm-ubuntu-20-04-1: Wed Nov 20 02:49:36 2024

tcp       25      0 10.5.220.4:53810        so:me:ip:add:443      CLOSE_WAIT  1074808/python3

Connections should be closed properly, and all client resources should be freed properly.

主要語言
Python
星號
233
分支
152
平均合併
21 小時 5 分鐘
30 天內合併 PR
10

貢獻指南

開啟貢獻指南

從這裡開始

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

databricks/databricks-sql-python 的其他 Issue

查看 databricks/databricks-sql-python 的全部 Issue

相似的 Issue

更多 Python Issue

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

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