Managing Pools

For a less detailed overview, see ServerPools. Pools fall under two main types, Sharded and Redundant. Sharded pools split the load amongst one or more redundant pools. Redundant pools mirror the same content across one or more processes. Most services inherit from WithPools which gives them a pools dictionary along with many functions for managing pools.

Every pool has a unique id or uid. This must be unique within all pools stored on that service throughout the cluster. Since pools are meant to be shared across multiple processes, they also have a dictionary of PoolMember (local) / CopiedPoolMember (remote) keyed by pool uid. These are used to communicate updates to other pool members such as adding or removing member processes, items, or any other changes.

Pool members have a priority assigned in order that they join. One member is elected master by having the highest priority in the group. The master pool is where most pool-wide changes are made. These changes are then mirrored out to other members.

Watchers and LifeGuards?

Sharded pools use LifeGuard objects in order to keep track of the pools they are load balancing across. LifeGuards can connect to any type of pool and they add a watcher on that pool which lets them be notified whenever processes join or leave the pool.

Redundant Pools

Redundant pools have a dictionary of HighlyAvailable items indexed by item id. They mirror these across all pool members. These pools are considered the owners of these items , so if the pool is deleted, all items are deleted as well. Items can be moved from one Redundant pool to another.

Sharded Pools

Unlike Redundant pools, Sharded pools don't actually store any items. What they do have is a mechanism for determining what shard pool any given item is on. The example RangeBased mechanism allows ranges of item ids to be defined for each shard in the Sharded pool.

Pool Lifetime

When a service WithPools starts up, it loads all Pools out of the store. Once the rest of the services on the process start up, it then calls loaded on each pool. Loaded attempts to connect to other pool members that were active when the service was shut down. If this fails (or there weren't any other pool members), then it becomes the master for that pool.