TCP connection not closing properly leading to dangling CLOSE_WAIT state and system overload
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- databases, networking
Research direction
Reproduce both cases using Python 3.10.15, databricks-sql-python 3.1.2, the shown sql.connect calls, and netstat to observe the socket states. Done means the connections close properly after the context manager or explicit close calls, with no indefinitely retained CLOSE_WAIT socket and client resources freed.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Python
- Stars
- 233
- Forks
- 152
- Avg merge
- 21h 5m
- Merged PRs (30d)
- 10
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from databricks/databricks-sql-python
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
All issues in databricks/databricks-sql-python
Similar issues
-
fix: inaccuracy ⚠️
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
uabrc/uabrc.github.io#1255 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
ethereum-optimism/factory#64 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
duckdb/duckdb-python#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Qiskit/qiskit-addon-sqd#376 ·