Poolex

Poolex is a library for managing pools of workers. Inspired by poolboy.

Table of Contents

• Poolex
  • Table of Contents
  • Features
  • Requirements
  • Installation
  • Usage
  • Guides
  • Contributions

Features

With poolex you can:

• Launch multiple pools of workers and then access the free ones from anywhere in the application.
• Configure the pool to run additional temporary workers if the load increases.
• Analyze and optimize your pool's production settings using metrics.
• Use your implementations to define worker and caller processes access logic.

Why poolex instead of poolboy?

• poolex is written in Elixir. This library is much more convenient to use in Elixir projects.
• poolboy is a great library, but not actively maintained 😿

Requirements

Requirement	Version
Erlang/OTP	>= 22
Elixir	>= 1.7

Installation

Add :poolex to your list of dependencies in mix.exs:

def deps do
  [
    {:poolex, "~> 1.0"}
  ]
end

Usage

In the most typical use of Poolex, you only need to start a pool of workers as a child of your application.

children = [
  {Poolex, 
    pool_id: :worker_pool,
    worker_module: SomeWorker,
    workers_count: 5}
]

Supervisor.start_link(children, strategy: :one_for_one)

Then you can execute any code on the workers with run/3:

iex> Poolex.run(:worker_pool, &(is_pid?(&1)), checkout_timeout: 1_000)
{:ok, true}

A detailed description of the available configuration or examples of use can be found in documentation.

Guides

• Getting Started
  • Starting pool of workers
  • Poolex configuration options
  • Working with the pool
• Migration from :poolboy
• Example of use
  • Defining the worker
  • Configuring Poolex
  • Using Poolex
• Working with metrics
  • Pool size metrics
  • Integration with PromEx
• Workers and callers implementations
  • Callers
  • Workers
  • Writing custom implementations

Contributions

If you feel something can be improved or have any questions about specific behaviors or pieces of implementation, please feel free to file an issue. Proposed changes should be taken to issues before any PRs to save time on code that might not be merged upstream.

If you are ready to change the project, please read the Contributing guide first.