how to set timeout for resource acquiring, NOT resource creating? about node-pool HOT 8 CLOSED

Yes, currently the acquire call will hang indefinitely.
There are a couple of ways to fix/change this that I can think of of the top of my head.
Adding in a "timeout-after-time-t" argument of somekind when make the acquisition request
but that seems a little limited, so I prefer the idea of the pool.acquire returning some opaque reference to the acquisition request (similar to how setTimeout and setInterval in nodejs work). That opaque reference could be used to cancel a request acquisition at somepoint later

e.g

var pool; //some already created instance of a `node-pool`

var resourceRequest = pool.acquire(someResourceAcquiredHandler);

//cancel the request - method name is pretty arbitary / bad
pool.clearAcquire(resourceRequest);

This way the user could cancel the resource request however/whenever they wanted to.

I'm pretty open to other suggestions/ideas though.

from node-pool.

I have encountered this problem. it look like a deadlock .

from node-pool.

maybe a super-simple version could just error immediately if the pool is full? a block argument which defaults to true, if false, raises an error if the pool is full..

from node-pool.

@kevinburkeshyp

I annoyingly haven't had any time to work on this yet. I'd like to have a proper solution for the next major version of this library, but in the meantime haven't come up with any decent "hack around" that would ok drop in the current v2 of the library. I'd love to have something current v2 users could use that isn't going to be a pain to move from when v3 is released

in terms of possible work arounds....

The current version of the pool does return a boolean from the pool.acquire function indicating whether the pool is currently fully utilised, false if the pool is at full "capacity" and cannot create any new clients, true if it isn't and should be able to create new clients.

This doesn't solve the problem of your callout knowing about it though....

Another option is to check the pool's availability before making requesting a resource using one/combination of these synchronous pool methods...

  me.getPoolSize
  me.availableObjectsCount 
  me.waitingClientsCount
  me.getMaxPoolSize

I'm not quite sure how these would all fit in with the ticket you raised on node-postgres though? Do you have easy access to pgs pool to use any of the above methods before deciding if to trying to grab a connection?

I'm wary of adding another argument to acquire, but it might represent a sensible stop gap for v2, it would probably have to be a generic opts style thing.

Anyway, I'm rambling, let me know what you think about any of this. Hopefully something above lets you do a quick fix, but hopefully we can get something into the library to make this less of a pain!

from node-pool.

Hi James,
Thanks for writing. I probably can get access to the node pool but I'd be a little worried about a race between reading the pool size and attempting to acquire a resource...

I'll keep thinking about a way to do this right...

from node-pool.

Patch here: #125, and #127

from node-pool.

I have exactly the same problem, and I got OOM with a huge wait clients list. Hopefully generic-pool can provide a safe net like maxWaitingClients, when something bad happens in the application the underlying pool can stop accept new requests to avoid OOM.

from node-pool.

this should now be fixed or at work-able round in v3
there is both a maxWaitingClients and acquireTimeout option

from node-pool.