How to create resizable pool router with new Typed router API?

Hi there,

I am trying to create resizable pool router with Akka Typed API. But it seems that new Typed router API does not support resizable pool.

Does this mean I will have to create resizable pool router with classic API and use it inside my typed Akka codes?

I tried with below:

import  //Adapter to mix classic API with typed one
object Worker {
  sealed trait Command
  case class DoLog(text: String) extends Command

  def apply(): Behavior[Command] = Behaviors.setup { context =>"Starting worker")

    Behaviors.receiveMessage {
      case DoLog(text) =>"{} got message {}",context.self , text)

object MainController {
  def apply(): Behavior[NotUsed] = {

       context => {
         //val config = ConfigFactory.load()
         val router: classic.ActorRef = context.actorOf(

         (0 to 10).foreach { n =>
           router ! Worker.DoLog(s"msg $n")


I got compiling error with “FromConfig.props(classic.Props[Worker])”. Because in classic API, Props[XX] => here XX is expected to be an Actor class instead of an object.

Maybe this is a stupid question since I am a totally newbie to both scala and akka.

Any tips will be appreicated

Hi, no there is no such router functionality built into the new typed APIs, we scoped down the routing logics to do much less as we think the huge API surface of routers in classic makes routers look more useful and important than they actually are.

Is there a concrete use case you are trying to cover with a resizable pool or are you just learning the APIs?

Hi there,

I am just learning the API. The reason why I wanted to use resizable pool router is that I was trying to setup some worker actors which do some long time calculation (normally 15-45 mins). And the intensity of calculation requests could fluctuate largely. When the concurrent requests is larger than the fixed pool size, the new incoming request will have to wait for long time.

But anyway, if resizable pool is not in scope of new API, maybe just try to evaluate the possible request peek value and setup a larger pool size for it.

Thanks a lot Johan

One option would be to skip the built in pool entirely and instead make your own pool-like parent actor that manages scaling the number of processing children up and down depending on in-flight requests. That will allow for a child-parent specific protocol about when payloads are completed etc.

Hi Johan,

Thanks a lot for the instruction