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
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.