Pooled connection checkout has no timeout: connect() hangs ~16 min on a dead socket
维护者通常 1 天内回复
评估
调研方向
Start by tracing pooled connection checkout in the driver, especially isAlive() and reset(); the issue identifies SQL_ATTR_CONNECTION_DEAD and SQL_ATTR_TXN_ISOLATION as relevant. Reproduce with the provided Python script against SQL Server, then inspect how connection validation and login timeouts are applied. Done means pooled checkout is bounded or the behavior is documented, as the issue requests.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
With pooling enabled, if a pooled connection's TCP socket has been silently dropped (no FIN/RST), the next connect() that reuses it blocks until the OS gives up on the socket. On Linux with the default net.ipv4.tcp_retries2=15 that is ~16 minutes. The login timeout doesn't apply. Once the socket errors, the pool opens a new connection and connect() returns successfully.
If several pooled connections are dead, one connect() checks them one after another.
From the source, isAlive() only reads the cached SQL_ATTR_CONNECTION_DEAD flag, so a dead socket passes it. reset() then sets SQL_ATTR_TXN_ISOLATION, which appears to be the call that waits on the server, with no timeout.
To reproduce
Client: python:3.12-slim-trixie container (linux/amd64), mssql-python==1.16.0, run with --cap-add NET_ADMIN. Server: mcr.microsoft.com/mssql/server:2022-latest, reachable as sqlserver.
import os, subprocess, time
import mssql_python
mssql_python.pooling(idle_timeout=600)
kw = dict(Server="sqlserver", UID=os.environ["DB_USER"], PWD=os.environ["DB_PASSWORD"], Encrypt="yes",
TrustServerCertificate="yes", timeout=15, autocommit=True)
conn = mssql_python.connect(**kw)
cur = conn.cursor()
cur.execute("select client_tcp_port from sys.dm_exec_connections where session_id = @@SPID")
port = cur.fetchone()[0]
conn.close() # back to the pool
# silently drop that connection's traffic (DROP, so no RST is sent)
subprocess.run(["iptables", "-A", "OUTPUT", "-p", "tcp", "--sport", str(port), "-j", "DROP"], check=True)
subprocess.run(["iptables", "-A", "INPUT", "-p", "tcp", "--dport", str(port), "-j", "DROP"], check=True)
time.sleep(8)
t = time.monotonic()
mssql_python.connect(**kw).close() # reuses the dead pooled connection
print(f"connect() took {time.monotonic() - t:.1f}s")
Results:
| Case | connect() duration |
|---|---|
tcp_retries2=15 (Linux default) |
951.8 s |
tcp_retries2=5 (--sysctl net.ipv4.tcp_retries2=5) |
~13 s |
3 dead pooled connections, tcp_retries2=5 |
29.5 s |
| Pooling disabled | 0.02 s |
The same happens on 1.15.0, and with autocommit=False. It doesn't happen if the socket was dead long enough for TCP keepalive to mark it dead first (~40 s with the default KeepAlive=30).
Expected behavior
Checking out a pooled connection should be bounded in time, for example by the login timeout or a separate validation timeout, with a timed-out candidate treated as dead. Alternatively, the checkout could avoid a server round trip. At minimum, the behaviour should be documented.
Further technical details
- Python version: 3.12.15
- mssql-python: 1.15.0 and 1.16.0
- SQL Server version: SQL Server 2022 (repro); also seen against Azure SQL Managed Instance
- Operating system: Debian 13 (trixie),
linux/amd64
Additional context
The investigation, repro and analysis were done with the help of Claude Opus 5.5. The results above were measured; the root-cause reading of the source is our interpretation and may be wrong.
- 主要语言
- Python
- 星标
- 479
- 派生
- 62
- 平均合并
- 2 天 23 小时
- 30 天内合并 PR
- 18
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoft/mssql-python 的其他 Issue
-
bulkcopy accepts four-part table names that SQL Server always rejects可能已有人在做 @jahnvi480 于 2 天前认领。 未关闭area: bulk-copy bug inADO triage done under development
难度 2/5 1-3 小时 新手友好度 70/100
microsoft/mssql-python#843 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
bulkcopy_arrow() / bulkcopy()` broken in 1.16.0可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭triage needed
难度 3/5 半天 新手友好度 72/100
microsoft/mssql-python#855 · 1 条评论 ·
维护者通常 1 天内回复
-
triage needed
难度 5/5 一周以上 新手友好度 38/100
microsoft/mssql-python#850 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
bulkcopy() & bulkcopy_arrow() fail with Schannel AcquireCredentialsHandleW error 0x8009030D (SEC_E_UNKNOWN_CREDENTIALS)可能已有人在做 @jahnvi480 于 2 天前认领。 未关闭area: bulk-copy bug inADO triage done
难度 4/5 3-5 天 新手友好度 20/100
microsoft/mssql-python#848 · 5 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
macOS: encrypted connections fail after Homebrew moved the `openssl` alias to `openssl@4`可能已有人在做 @bewithgaurav 于 22 天前认领。 未关闭area: packaging-platform bug triage needed
难度 4/5 3-5 天 新手友好度 55/100
microsoft/mssql-python#826 · 2 条评论 · 3 个 reaction · 已指派 1 人 ·
维护者通常 1 天内回复
查看 microsoft/mssql-python 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
CLIMADA-project/climada_python#1337 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
8go/matrix-commander#233 ·
-
documentation
难度 2/5 1-3 小时 新手友好度 66/100
-
documentation enhancement priority:high size:M
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
Validate non-divisible effective batch sizes in the Unsloth LoRA backend可能已有人在做 @debesh-biswas 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 70/100