evolution-gaming / resource-pool

Pool of cats-effect resources

resource-pool

Pool of cats-effect resources

Features:

• allocates resources on demand up to configured limit
• deallocates resources if not active for a configured time
• tries to minimize number of resources in the pool
• uses first-in-first-out queue for tasks
• shuts down gracefully after completing accumulated tasks
• tolerates resource failures
• supports cancellation

Example

import com.evolution.resourcepool.ResourcePool.implicits._

trait Connection {
  def query(): IO[Any]
}

def connection: Resource[IO, Connection] = ???

connection
  .toResourcePool( // you can convert any resource into the pool of resources
    maxSize = 10, // it will create up to `maxSize` connections 
    expireAfter = 1.minute) // pool will release connection if it is not used for 1 minute
  .use { connectionPool =>
    connectionPool
      .resource // this will get first available connection or allocate one
      .use { connection =>
        connection.query() // here you have access to the connection
      }
  }

Setup

addSbtPlugin("com.evolution" % "sbt-artifactory-plugin" % "0.0.2")

libraryDependencies += "com.evolution" %% "resource-pool" % "1.0.2"

resource-pool's Issues

Questions and code improvement suggestions

I have some questions and suggestions for improving the code. Feel free to ignore stylistic suggestions because they're subjective.

1. I don't think we should expose IntHelper as a part of public API, I'd mark it as private[resourcepool].

2. Do we really need implicits in our public API (IntHelper, ResourcePoolOps)? IMO introducing an implicit is justified only if it's going to be used a lot of times. How many times a user is going to construct a pool in his code? Probably once or twice. So I think it's much easier for the user to have an explicit method and not think about what they need to import.

3. If I understand correctly, cancellation works differently for ResourcePoolOps.resource than for ResourcePool.get. cats.effect.Resource.apply makes acquire and release uncancelable. I think this change in cancellation semantics can be a surprise for the users, so I'd mention it in the scaladoc for ResourcePoolOps.resource.