Reputation: 689
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
https://i.sstatic.net/PRmwE.png
Upvotes: 2
Views: 575
Reputation: 2938
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.
Upvotes: 3