Pool2 is a generic resource pooling library for Node.js, designed to efficiently manage expensive, reusable resources like database connections or network sockets. It provides a configurable framework for acquiring, releasing, disposing, and destroying resources, incorporating essential features such as minimum and maximum pool sizes, idle timeouts, request queuing, and health checks (ping functions). Key differentiators include its robust handling of resource lifecycle events and explicit timeouts for acquire and dispose operations, which helps prevent resource leaks and ensure application stability. The package is currently at version 1.4.1. While a specific release cadence isn't defined, the documentation indicates it's a mature and stable solution for resource management, offering fine-grained control over resource behavior and pooling strategies.
npm install pool2Verified import paths — ran on the pinned version, not inferred.
Demonstrates the basic creation of a resource pool, acquiring and releasing resources, and observing pool statistics. It includes custom acquire/dispose/destroy functions with asynchronous operations and pool shutdown.
Implement connection-level timeouts within your `acquire` function's resource creation logic. For instance, if connecting to a database, ensure the database driver's connection timeout is set and that a timeout error from the driver is passed to the `acquire` callback to properly notify `pool2`.
Ensure your `dispose` function thoroughly attempts to close the resource and handles potential errors gracefully. Log any `dispose` failures prominently to identify and debug resource leakage issues promptly. Consider a more aggressive cleanup in the `destroy` function if `dispose` fails.
Keep `destroy` logic idempotent and non-blocking if possible. Critical cleanup that *must* complete should ideally be handled within a robust `dispose` function, or with external monitoring for resources that `destroy` attempts to clean up.
Carefully balance `min` and `max` based on your application's typical and peak load. Set `idleTimeout` to reclaim unused resources, but ensure it's shorter than any upstream server-side timeouts (e.g., database `wait_timeout`) to prevent stale connections. Monitor pool metrics (`pool.stats()`) in production to fine-tune these values.
Increase `acquireTimeout` if the resource truly takes longer to provision, or set `requestTimeout` if waiting for an available resource. More importantly, check if the underlying resource acquisition in your `acquire` function has its own timeouts and handles them by reporting failure to `pool2`'s callback. Also verify `max` pool size and `maxRequests` are adequate for your load.
Thoroughly review the `dispose` function implementation to ensure all necessary steps are taken to gracefully close the resource. Add logging for `dispose` failures to quickly identify and troubleshoot issues related to resource leakage. Consider integrating a linter or static analysis tool to catch unhandled promises or forgotten callbacks.
No dependency data recorded yet.