Pooled connection checkout has no timeout: connect() hangs ~16 min on a dead socket
Les mainteneurs répondent en général sous 1 jour
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 48/100
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Python
- Étoiles
- 479
- Forks
- 62
- Merge moyen
- 2 j 9 h
- PR mergées (30 j)
- 18
Préparer son environnement
Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de microsoft/mssql-python
-
bulkcopy_arrow() / bulkcopy()` broken in 1.16.0Peut-être pris @jahnvi480 l’a pris il y a 1 jour. Ouvertearea: bulk-copy bug inADO triage done under development
Difficulté 3/5 Une demi-journée Accessibilité débutants 72/100
microsoft/mssql-python#855 · 2 commentaires · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
triage needed
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 38/100
microsoft/mssql-python#850 · 2 commentaires · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
bulkcopy() & bulkcopy_arrow() fail with Schannel AcquireCredentialsHandleW error 0x8009030D (SEC_E_UNKNOWN_CREDENTIALS)Peut-être pris @jahnvi480 l’a pris il y a 3 jours. Ouvertearea: bulk-copy bug inADO triage done
Difficulté 4/5 3-5 jours Accessibilité débutants 20/100
microsoft/mssql-python#848 · 5 commentaires · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
macOS: encrypted connections fail after Homebrew moved the `openssl` alias to `openssl@4`Peut-être pris @bewithgaurav l’a pris il y a 23 jours. Ouvertearea: packaging-platform bug triage needed
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
microsoft/mssql-python#826 · 2 commentaires · 3 réactions · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
Announcement: mssql-python is coming to Django through mssql-django 2.0Peut-être à nouveau libre @bewithgaurav l’a pris il y a 49 jours, et aucune pull request n’est ouverte. Ouverteannouncement
microsoft/mssql-python#748 · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de microsoft/mssql-python
Issues similaires
-
Difficulté 1/5 1-3 heures Accessibilité débutants 88/100
fossasia/visdom-dev#69 ·
Les mainteneurs répondent en général sous 3 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
Les mainteneurs répondent en général sous 1 jour
-
Frontend build fails with Frappe version-16: DataImport is no longer exported by @framework/uiOuvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
BUG: PROD: v1.3.0-beta Onboarding Profile Picture Misaligns When Name Validation Error AppearsPeut-être pris @RitikaSen27 l’a pris aujourd’hui. Ouvertebug good first issue
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
AOSSIE-Org/PictoPy#1647 · 2 commentaires ·
Les mainteneurs répondent en général sous 2 jours
-
[oblt-aw][autodoc] Update workflow docs for gh-aw v0.92.5 and detector permission scopePeut-être pris @github-actions l’a pris aujourd’hui. Ouverte
Difficulté 1/5 1-3 heures Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour