Skip to content

Latest commit

 

History

History
48 lines (46 loc) · 2.47 KB

NEWS.org

File metadata and controls

48 lines (46 loc) · 2.47 KB
Raw

1.0.0

Breaking Changes (upgrading from 0.0.x)

pooler application config format changes

Pool names in config must be atoms, not strings.

API changes

  1. The function pooler:take_member/0 has been removed.
  2. Pool names are now atoms not strings. An atom matching a configured pool name is expected by pooler:take_member/1.
  3. For load balancing a collection of related pools, you must use the new group API functions: pooler:take_group_member/1 and pooler:return_group_member/2. A group attribute can be specified as optional config for each pool. Pools with the same group name form a group.

What’s New

Improved support for multiple independent pools

Each pool is now serviced by its own gen_server with an independent supervision tree. This makes pooler a good fit when you need to pool different unrelated clients, for example Redis and Riak. Independent pools will not contend for the same server mailbox as was the case in version 0.0.x and the supervision structure should isolate failures such that a high crash rate in one pool should not take down an unrelated pool.

Asynchronous and parallelized member creation

Members are started and added to pools asynchronously. This is a major improvement when pooling members with substantial startup time. Instead of the entire pool being blocked while a new member is started, the pool can continue to process messages.

When a pool is initialized, all init_count members are started in parallel. The pool does not start processing messages until all initial members have been added. This reduces the overall time-to-start for pooler compared to version 0.0.x where initialization of members was handled serially.

Once running, new members are added in batches of size init_count up to max_count. Batches are added after the pool returns a single error_no_members value for a pool. This means a pool will always return at least one error_no_members value when growing beyond init_count size. This approach has the benefit of not penalizing a steady load of init_count members in use. If members addition were to be triggered before init_count were in use, then members would be added to the pool, never used, and culled after the configured timeout.

The pooler server uses monitors not links

In pooler 0.0.x, pooler was a system process that trapped exits and linked to members and consumers. Monitors are now used instead to reduce the potential impact of a pooler related crash and to simplify the code.