嗨，由于我无法正确解决问题，这可能不是我所提问题的正确标题，但实际情况是这样；
演员A创建演员B1，而演员B1创建负责执行任务的“ n”个演员。因此，A是B1的父级，而B1是b1，b2，b3，...的父级。
在A中，我安排了一个自动收录器，以便A每10秒检查一次是否有新的B'要创建。
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());
在前端，我可以调整“ b”个任务的并行度。例如，如果我将并行度设置为3，则B（1）创建3个actor，每个actor执行某个任务，如果一个actor，使b（n）结束，则创建b（n + 1），依此类推。
问题是 ;
如果只有一个由演员“ B'”创建的演员b（i = 1）（该B不重要），则记号器会每10秒真正滴答一声，但是如果我将b的平行度提高到64 b （i = 64），则股票行情不会表现得很好。它等待相当长的时间，例如1分钟。然后滴答滴答6次，好像有一个冲洗机械。
当我增加系统参与者的数量时，这不是我遇到的唯一问题。
我有一个API，以便用户将订单发送给演员，如下所示
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()));
当大约有10个参与者时，期货总是超时，但是当我调试代码时，我看到消息已接收，但是经过了很长一段时间。
因此，我想知道是什么阻止了Actor A接收消息。我尚未检查演员B'及其孩子的同一个问题，但是如果我发现这个问题我相信我可以将解决方案应用于其他人。
感谢您的任何建议。
层次结构是这样的
默认情况下，所有Akka参与者都使用同一执行器，该执行器最多只能使用64个线程。从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
}
问题可能与阻止b * actor中的调用有关。Akka从64个池中分配单独的线程来处理b * actor中的这些阻塞调用，并等待它们中的一个完成消息处理，以便能够处理A和B的消息。
有关如何解决此问题的想法，请参阅http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html中的“阻止需要仔细管理” 。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句