Akka演员阻止消息

Question

Hi since i am unable to address the problem correctly this may not be the proper title for my question but here is the case ;

Actor A creates Actor B1 and Actor B1 creates "n" actors which are responsible for execiting tasks. So A is parent of B1 and B1 is parent of lets say b1, b2, b3, ....

In A i have scheduled a ticker so that A checks every 10secods if there is a new B' to create.

Duration duration = Duration.create(10 sec.);
FiniteDuration interval = new FiniteDuration(duration.toMillis(), TimeUnit.MILLISECONDS);
ticker = getContext().system().scheduler().schedule(interval, interval, getSelf(), new Tick() { }, getContext().dispatcher(), getSelf());

On front end i can adjust the parallel degree of number of "b" tasks. For example if i set the parallel degree to 3 then B(1) creates 3 actors and each actor executes some task and if one actor , lets say b(n), finishes than b(n+1) is created and so on.

The problem is ;

If there is only one actor b(i=1) that is created by Actor "B'" (which B is not important) than ticker really ticks every 10 seconds, but if i increase the parallel degree of b's to lets say 64 b(i=64) then tickers doesnot behave properley. It waits quite a long time for example 1 min. then ticks 6 times consequtively as if there is a flush mechanisim.

And this is not the only problem i got when i increase the number of actors on the system.

I have a api so that user sends orders to actors like below

String path = ActorPaths.actorPathForPlan(plan);
ActorSelection actorSelection = runtimeInit.getSystem().actorSelection(path);
// ask
Timeout timeout = new Timeout(Duration.create(4*1000, TimeUnit.MILLISECONDS));
Future<Object> future = Patterns.ask(actorSelection, message, timeout);
// get result
return returnType.cast(Await.result(future, timeout.duration()));

when there is more than approximitely 10 actors then futures always times out but when i debug the code i see the message is recived but after quite a long time.

So, I wonder what is blocking my Actor A from receiving messages. The same problem may be occuring in actor B' and its children i didn't checked yet but if i figure out the problem i belive i can apply the solution to others.

Thanks for any suggestions.

The hiararchy is like this

http://i.stack.imgur.com/PRmwE.png

Answer 1

By default all Akka actors use the same executor which is limited to use 64 threads maximum. From http://doc.akka.io/docs/akka/snapshot/general/configuration.html :

# This will be used if you have set "executor = "default-executor"".
      # If an ActorSystem is created with a given ExecutionContext, this
      # ExecutionContext will be used as the default executor for all
      # dispatchers in the ActorSystem configured with
      # executor = "default-executor". Note that "default-executor"
      # is the default value for executor, and therefore used if not
      # specified otherwise. If no ExecutionContext is given,
      # the executor configured in "fallback" will be used.
      default-executor {
        fallback = "fork-join-executor"
      }

      # This will be used if you have set "executor = "fork-join-executor""
      fork-join-executor {
        # Min number of threads to cap factor-based parallelism number to
        parallelism-min = 8

        # The parallelism factor is used to determine thread pool size using the
        # following formula: ceil(available processors * factor). Resulting size
        # is then bounded by the parallelism-min and parallelism-max values.
        parallelism-factor = 3.0

        # Max number of threads to cap factor-based parallelism number to
        parallelism-max = 64
      }

The problem is likely related to blocking calls in b* actors. Akka assigns separate threads from a pool of 64 to handle these blocking calls in b* actors and waits for one of them to complete message processing to be able to handle messages for A and B.

See "Blocking Needs Careful Management" in http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html for ideas how to work around this issue.