Skip to content


Subversion checkout URL

You can clone with
Download ZIP


closes #56 - idle resources below the "min" value not destroyed #57

merged 2 commits into from

3 participants


No description provided.


I've reviewed the travis build failure, but can't figure out why or what test is failing.


Hi there,

I haven't looked at the build failure yet either, but I'd like to discuss this change. The current implementation respects both the "min" and "idleTimeoutMillis" properties on the pool. The behavior you saw in #56 doesn't surprise me too much, although I'd have to see your full program to know if the timings match what I would expect.

Your idleTimeoutMillis was set quite low, so the observed behavior was pathological. But some folks are using this setting to ensure that their pool of, say, database connections, hasn't gone stale. idleTimeout might be something like 2 minutes, and the pool promises that the elements in the pool have been active within idleTimeout.

I don't want to lose that behavior, as some folks are relying on it.

Given your settings it seems that idleTimeoutMillis is never doing much for you. What if we tweak your patch so that your change takes effect if idleTimeoutMillis < 0? That would allow your pool to dynamically size between min/max, but whenever removeIdle() runs you'll size down to min. Effectively reapIntervalMillis would govern how quickly your pool sizes back down to min, and you could adjust that depending on how quickly you wanted to size down.



I've added the refreshIdle flag as discussed above, defaulting to 'true' so that original functionality is maintained.


Will this issue be merged soon? I've applied this commit locally for testing and it fixes a runaway pool for me when a database error is thrown. Without this fix, my getPoolSize() shows ever decreasing negative numbers and the availableObjectsCount() increases well passed the max connections until the database throws a TOO MANY CONNECTIONS error.

Without this fix it makes it very difficult for me to use generic-pool, which is a shame because I've used it successfully in the past!


@coopernurse coopernurse merged commit 69992f7 into coopernurse:master

Ok this is in master -- Could either of you give it a go? If I get a thumbs up I'll publish to npm


I can confirm that with the new merge and setting refreshIdle to false my issue is fixed.



Terrific. Thanks for the quick reply. v2.0.3 is tagged and published to npm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Dec 14, 2012
  1. @wshaver
Commits on Dec 19, 2012
  1. @wshaver
This page is out of date. Refresh to see the latest.
Showing with 4 additions and 3 deletions.
  1. +4 −3 lib/generic-pool.js
7 lib/generic-pool.js
@@ -88,7 +88,8 @@ var PriorityQueue = function(size) {
* that will be used instead. The function expects the arguments msg, loglevel
* @param {Number} factory.priorityRange
* The range from 1 to be treated as a valid priority
- *
+ * @param {RefreshIdle} factory.refreshIdle
+ * Should idle resources be destroyed and recreated every idleTimeoutMillis? Default: true.
* @returns {Object} An Object pool that works with the supplied `factory`.
exports.Pool = function (factory) {
@@ -96,7 +97,7 @@ exports.Pool = function (factory) {
idleTimeoutMillis = factory.idleTimeoutMillis || 30000,
reapInterval = factory.reapIntervalMillis || 1000,
+ refreshIdle = ('refreshIdle' in factory) ? factory.refreshIdle : true,
availableObjects = [],
waitingClients = new PriorityQueue(factory.priorityRange || 1),
count = 0,
@@ -158,7 +159,7 @@ exports.Pool = function (factory) {
// Go through the available (idle) items,
// check if they have timed out
- for (i = 0, al = availableObjects.length; i < al; i += 1) {
+ for (i = 0, al = availableObjects.length; i < al && (refreshIdle || (count - factory.min)) > toRemove.length ; i += 1) {
timeout = availableObjects[i].timeout;
if (now >= timeout) {
// Client timed out, so destroy it.
Something went wrong with that request. Please try again.