Class Routers

java.lang.Object
org.apache.pekko.actor.typed.javadsl.Routers

public class Routers extends Object
  • Constructor Summary

    Constructors
    Constructor
    Description
     
  • Method Summary

    Modifier and Type
    Method
    Description
    static <T> GroupRouter<T>
    group(ServiceKey<T> key)
    A router that will keep track of the available routees registered to the pekko.actor.typed.receptionist.Receptionist and route over those by random selection.
    static <T> PoolRouter<T>
    pool(int poolSize, Behavior<T> behavior)
    Spawn poolSize children with the given behavior and forward messages to them using round robin.

    Methods inherited from class java.lang.Object

    clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
  • Constructor Details

    • Routers

      public Routers()
  • Method Details

    • group

      public static <T> GroupRouter<T> group(ServiceKey<T> key)
      A router that will keep track of the available routees registered to the pekko.actor.typed.receptionist.Receptionist and route over those by random selection.

      In a clustered app this means the routees could live on any node in the cluster. The current impl does not try to avoid sending messages to unreachable cluster nodes.

      Note that there is a delay between a routee stopping and this being detected by the receptionist, and another before the group detects this, therefore it is best to deregister routees from the receptionist and not stop until the deregistration is complete if you want to minimize the risk of lost messages.

    • pool

      public static <T> PoolRouter<T> pool(int poolSize, Behavior<T> behavior)
      Spawn poolSize children with the given behavior and forward messages to them using round robin. If a child is stopped it is removed from the pool, to have children restart on failure use supervision. When all children are stopped the pool stops itself. To stop the pool from the outside, use ActorContext.stop from the parent actor.

      Note that if a child stops there is a slight chance that messages still get delivered to it, and get lost, before the pool sees that the child stopped. Therefore it is best to _not_ stop children arbitrarily.