Pooled connection checkout has no timeout: connect() hangs ~16 min on a dead socket
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Python
- Stelle
- 479
- Fork
- 62
- Merge medio
- 2g 9h
- PR unite (30g)
- 18
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/mssql-python
-
bulkcopy_arrow() / bulkcopy()` broken in 1.16.0Forse già presa @jahnvi480 l’ha presa 1 giorno fa. Apertaarea: bulk-copy bug inADO triage done under development
Difficoltà 3/5 Mezza giornata Idoneità per principianti 72/100
microsoft/mssql-python#855 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
triage needed
Difficoltà 5/5 Più di una settimana Idoneità per principianti 38/100
microsoft/mssql-python#850 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
bulkcopy() & bulkcopy_arrow() fail with Schannel AcquireCredentialsHandleW error 0x8009030D (SEC_E_UNKNOWN_CREDENTIALS)Forse già presa @jahnvi480 l’ha presa 3 giorni fa. Apertaarea: bulk-copy bug inADO triage done
Difficoltà 4/5 3-5 giorni Idoneità per principianti 20/100
microsoft/mssql-python#848 · 5 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
macOS: encrypted connections fail after Homebrew moved the `openssl` alias to `openssl@4`Forse già presa @bewithgaurav l’ha presa 23 giorni fa. Apertaarea: packaging-platform bug triage needed
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
microsoft/mssql-python#826 · 2 commenti · 3 reazioni · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Announcement: mssql-python is coming to Django through mssql-django 2.0Forse di nuovo libera @bewithgaurav l’ha presa 50 giorni fa e non c’è nessuna pull request aperta. Apertaannouncement
microsoft/mssql-python#748 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di microsoft/mssql-python
Issue simili
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
sergey-miryanov/gcmon#230 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Azure-Samples/azure-search-openai-demo#3249 ·
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Failed archive extraction deletes the dataset cacheForse già presa @dajiaohuang l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
alibaba/GraphScope#4674 ·