coopernurse
idleTimeoutMillis is not working with generic-pool 3.x
Hi Team, I have upgraded generic-pool library from 2.x to 3.x. I have created a pool using
genericPool.createPool({
create: function(){
return new promise(function(resolve,reject){
// create client
resolve(client);
});
},
destroy: function(client){
return new Promise(function(resolve){
client.on('end', function(){
resolve()
})
client.end()
});
},{configParams});
idleTimeoutMillis timeout is set to 30ms. genericpool is not creating new resourse after 30ms.
Hi there,
I think this is problem of the docs not being very clear! Unless evictionRunIntervalMillis is set to number greater than 0, neither softIdleTimeoutMillis nor idleTimeoutMillis have any effect.
evictionRunIntervalMillis sets how how often idle resources are checked and by default it's zero, i.e. resources are never checked.
I should do something to make this more clear!
Hi, idleTimeout is working now. But there is a problem with the pool.drain(). case 1. Lets say I am not releasing resource to pool and keep calling pool.acquire(). I have set acquireTimeoutMillis to 30s , thus After 30s pool.acquire will throw timeout error. After receiving timeout error, I am calling pool.drain()
pool.drain().then(function() { console.log('pool drained :::::::::::'); return pool.clear(); }); But, callback specified in then never called , "pool drained :::::::::::" has not printed. Am I missing something?
If you borrow a resource from the pool, but then never return it, the pool will not drain,
or to it put another way, pool.drain will wait for all outstanding resources to be returned before resolving.
Currently there isn't concept of "abandoned resources" (I.e those which have been borrowed, then lost/forgotten about and not returned) so the pool can't just ignore them. It's vaguely on the roadmap to add but I've not given it any serious planning yet.
Problem with the node pool is when pool.acquire throws Timeout error, pool still contains resources and thus when I throw err node process doesnot exit. This scenario occurs only when pool is exhausted.
I think the behaviour you are talking about it is by design so you can decide you how you want your application to behave.
The pool throwing timeoutError may not be fatal for you code, you might just log out the error and keep the pool/app running, or you might want to close the app.
If you want the pool to close after a timeoutError you will need to manually call drain etc.
My issue is after getting timeoutError , Pool doesnot allow node process to terminate (in case All pool resources are acquired and never released).
If you want the process to exit without first returning all the borrowed resources to the pool, your only option is to just crash the process. There is no way to "force close" the pool, and even if there was it would probably just end up with the same result
Hi, I'm confused about idleTimeoutMillis and evictionRunIntervalMillis, I had read the README.md but I still can't distinguish it. Can anyone explain the difference...?
@George0406 sure:
idleTimeoutMillis specifies the threshold for deciding if an resource has been idle for too long. However, crossing this threshold does not directly cause the resource to be evicted/destroyed. The actual eviction/destruction process is handled separately by the evictor (lol), which runs periodically every evictionRunIntervalMillis.
Or to put it another way, the evictor runs every evictionRunIntervalMillis, and checks numTestsPerRun resources inside the pool that are waiting to be borrowed, and if a resource has been idle for longer than idleTimeoutMillis, destroys it.
@sandfox Thanks for the quick reply
Sorry, I had typed wrong paramters in the previous question, I would like to ask what is the difference between idleTimeoutMillis and softIdleTimeoutMillis, and thanks for your reply again.
@George0406 no problem.
softIdleTimeoutMillis is pretty much like idleTimeoutMillis except it only applies to "excess" resources in the pool. If the pool has 10 resources in it which have been idle too long and a min size of 4, then only 6 of the resources will eligible to be destroyed.
Does that help?
@sandfox: If my my pool configuration is set like so, would not explicitly setting the evict property cause ETIMEDOUT errors?
Here is my configuration:
pool: { max: 10, min: 1, idle: 10000 }
@sandfox softIdleTimeoutMillis is pretty much like idleTimeoutMillis except it only applies to "excess" resources in the pool. If the pool has 10 resources in it which have been idle too long and a min size of 4, then only 6 of the resources will eligible to be destroyed.
===================================== After I try both of then, it is seen like idleTimeoutMillis more like above description? When I setting idleTimeoutMillis 10000, after 10 seconds those connection(max - min) will be kill, but softIdleTimeoutMillis not. Can you check this? thanks!!
@zxc7922927 could supply some example code? Something to bear in mind is that the as soonas you set evictionRunIntervalMillis to any non-zero value, the default setting for idleTimeoutMillis (30 seconds) will take effect along with any value you supply for softIdleTimeoutMillis
@sandfox here is my setting: { refreshIdle: false, connection_min: 1, connection_max: 50, acquire_timeout: 5000, idleTimeoutMillis: 10000 } After using apachebench stress test, when I check process list, there has some sleep connections. After 10 seconds, they has been destroyed but keep one connection in there. But when I replace idleTimeoutMillis with softIdleTimeoutMillis, those connections just keep in there, won't be destroyed.