Additional Configuration Features

• Acquire Timeout: Not sure if we want this a part of the pool or just user controlled. When a maximum number of connections exist and we are waiting. We may want to timeout this acquisition directly.

• Maximum Lifetime: Resource are currently only based on their period of idle. However we may want to set a resource lifetime that after that point after it is returned to the pool or if it is already in the pool that it is removed.

• Resource Valid Check: Often we may want to ensure resources in the pool are still valid. A TCP connection may be closed from the remote side. A database connection may check if it is stil valid. These can be integrated into both the reaping and/or the acquisition so only valid resources are received by users.

• Validation timeout after which we should assume the above resource is invalid

• Minimum Idle Option: Precache and load up resources so that they are already present in the cache. This is important for databases and far less so for things like http. i.e. This is only valid over bounded keyspaces.

• Max Total Option: Maximum total number of resources both in and loaned from the pool. Presently we only control how many are in the pool but this can allow runaway resources if they are held by users.

• Leak Detection Threshold: A time period a resource can leave the pool before a warning is emitted. Default should not log, but should have the option to make sure people can discover their leaks.

Start by reading the existing pool implementation and its current resource and idle-period behavior. The issue lists several possible features, including acquisition timeouts, maximum lifetime, validation, minimum idle resources, total limits, and leak detection; done would require a decided scope and acceptance criteria for the selected configuration changes.