Relationships
#1709 Datastore MongoDB driver leaks connections — 5960 accumulated over 8 days
Opened by magistr · 8/18/2026
Summary
The swamp datastore's MongoDB driver (nodejs v6.17.0 via Deno) accumulates connections over time without closing them. After 8 days of uptime, MongoDB showed ~5960 concurrent connections all from the same swamp client ([IP-1]), pushing memory to the 4g cgroup limit and causing Docker healthcheck failures.
Observed behavior
connectionCountin MongoDB logs climbed to ~5960 over 8 days- All connections originated from a single swamp client IP ([IP-1]) using the Deno nodejs MongoDB driver v6.17.0
- Container memory reached 4041 MB / 4096 MB (4g mem_limit)
- WiredTiger cache is configured at 2 GB (
--wiredTigerCacheSizeGB 2), so the remaining ~2 GB was consumed by connection overhead - Docker healthcheck (
mongosh --quiet --eval "db.adminCommand('ping').ok"with 10s timeout) started failing — themongoshprocess couldn't complete within timeout under memory pressure - Manual
db.runCommand({ping:1})still succeeded (the database itself was responsive) container_last_seenmetric was current — cAdvisor saw the container as alive
Expected behavior
The driver should close idle connections and maintain a bounded connection pool. Connection count should stabilize at the pool size, not grow linearly with uptime.
Reproduction
Run any swamp repo with a MongoDB datastore for several days. Monitor connectionCount in MongoDB logs (visible in the "Connection accepted" log entries). The count will grow monotonically.
Environment
- MongoDB: mongo:7 (v7.0.34), single-node replica set rs0 with keyFile auth
- Driver: nodejs v6.17.0 via Deno v2.8.3
- Container: 4g mem_limit,
--wiredTigerCacheSizeGB 2 - Swamp version: 20260814.234054.0-sha.7823c130
Workaround
Restart the MongoDB container periodically to clear leaked connections. Consider adding maxIncomingConnections to mongod config as a safety cap.
Closed
No activity in this phase yet.
magistr commented 8/18/2026, 4:36:41 PM
Correction on root cause: the connection accumulation is not from idle connection leaks — it occurred under additional load. The swamp client was actively running model methods and workflows, and the driver opens new connections under load without properly returning them to the pool or closing them when done. The growth correlates with activity volume, not idle time.
stack72 commented 8/18/2026, 5:13:00 PM
@magistr I believe this needs to be opened https://github.com/keeb/swamp-mongodb-datastore
Sign in to post a ripple.