[BUG] Connection pool grows correctly but never shrinks back
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 38/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- javascript, node.js
- 領域
- database
調査の方向性
まず README.md のプールオプションとライフサイクルのドキュメントを確認し、次に shrink: true を指定して pool.query() と pool.connect() を使い、問題を再現します。ドキュメントに記載された動作が、負荷後に観測された pool.poolSize と一致するか確認します。決定論的な縮小が機能するか、動作とクリーンアップの制御方法が明確に文書化されていれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Describe your system
odbcPackage Version: 2.4.8- ODBC Driver: IBM DB2 ODBC DRIVER
- Database Name: DB2
- Database OS: IBM i (AS/400)
- Node.js Version: 18.17.1
- Node.js OS: IBM i
Describe the bug
When using the built-in connection pool with shrink: true, the pool grows beyond initialSize under load but does not shrink back once the load is gone. After all queries have completed and all connections have been released, pool.poolSize remains permanently greater than initialSize, even after a long idle period.
This behavior occurs both when using pool.query() and when explicitly acquiring and releasing connections using pool.connect() and connection.close().
Expected behavior
With shrink: true, once all connections are released and the system becomes idle, the pool should eventually shrink back to initialSize, or at least have a documented, deterministic behavior regarding when or if shrinking occurs.
To Reproduce
- Create a pool with the following options:
const pool = await odbc.pool({ connectionString, initialSize: 2, incrementSize: 1, maxSize: 20, shrink: true }); - Run multiple queries in parallel to force the pool to grow
await Promise.all(
Array.from({ length: 10 }, () =>
pool.query("SELECT 1")
)
);
#or using explicit connections:
const conn = await pool.connect();
await conn.query("SELECT 1");
await conn.close();
- Wait until all queries have completed.
- Log pool.poolSize
Additional context
Calling connection.close() seems to only return the connection to the pool and does not close the actual database connection. There does not appear to be a documented idle timeout or automatic cleanup of extra connections. As a result, once the pool grows beyond initialSize, it stays larger even when the application is idle. This makes it hard to control the total number of open database connections.
Is this behavior expected by design? If so, it would be helpful to clarify this in the documentation or provide a deterministic way to shrink or evict idle connections.
- 主要言語
- JavaScript
- スター
- 159
- フォーク
- 92
- 平均マージ
- 5時間 59分
- マージ済み PR（30日）
- 3
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
IBM/node-odbc のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
-
security
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
[Bug] Sybase ASE: Encoding issue (works in msnodesqlv8, fails in node-odbc with \x1A artifacts)オープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 28/100
似ている issue
-
clawsweeper:needs-product-decision clawsweeper:needs-security-review clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:security issue-rating: 🦞 diamond lobster P2
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
openclaw/openclaw#166870 · コメント 2 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
⚠ needs intervention document structure changed
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
Bug pulumi/pulumi
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
uoftblueprint/canada-basketball#32 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
andromarces/agent-loops#571 ·
メンテナーはふだん 1 日以内に返信