About Joining the Space as a Seeder or a Leech

There are some factors that determine when your application must join a space as a seeder or a leech.

Consider the following points before deciding on the role played by your application:

  • Even though ActiveSpaces has a true peer-to-peer architecture, rather than a client-server architecture, you can deploy applications as leeches (effectively, as clients of the space service) with as-agents acting as a server cluster.
  • For some operations, an application that joins a space as a seeder experiences better performance than it would as a leech, but this comes at the expense of higher RAM and CPU usage.
  • The entries in the space are stored randomly using a hash of the value(s) of the key field(s) (in practice as good as random), but are stored evenly between all of the seeders of the space. Seeders do not necessarily seed what they put in the space.
  • The distribution role (seeder or leech) is only a level of participation—not a limitation on use. Leeches have access to the same set of space operations as seeders.
  • You can also use the as-agent process to “keep the data alive” when all of the instances of an application have disconnected from the metaspace.
  • When a seeder joins or leaves a space, there might be a temporary impact on space performance while redistribution is performed. On the other hand, leeches do not incur any impact when joining or leaving a space.

The choice of distribution role must be made on a per space basis: the best solution may be to join some spaces as a seeder and others as a leech.

Related concepts