使用@inject时的参与者数

Question

我正在构建一个应用程序在Play框架，必须做一些紧张的文件解析。这种解析包括解析多个文件，最好是并行的。用户上传一个解压的归档文件，文件存储在驱动器上。在该存档中，有一个文件（我们称之为main.csv)，它有多个列。其中一列是归档文件中另一个文件的名称（如subpage1.csv)。此列可以为空，这样main.csv中的所有行都没有子页。

现在，我启动一个Akka Actor来解析main.csv文件。在这个actor中，使用@inject，我有另一个ActorRef

public MainParser extends ActorRef {
    @Inject
    @Named("subPageParser")
    private AcgtorRef subPageParser;

    public Receive createReceive() {
        ...
        if (column[3] != null) {
            subPageParser.tell(column[3], getSelf());
        }
    } 
}

SubPageParser道具：

public static Props getProps(JPAApi jpaApi) {
    return new RoundRobinPool(3).props(Props.create((Class<?>) SubPageParser.class, jpaApi));
}

List<String> names = dao.getNames();
for (String name: names) {
    subPageParser.tell(name, null);
}

在本例中，考虑到subpageParserActorRef是像以前一样使用Guice@inject获得的，我会进行并行处理吗？

如果我在并行处理，我如何控制正在产生的参与者的数量？如果我有1000个子页，我不想要1000个演员。此外，他们的寿命可能是一个问题。

注意：我有一个像这样的ActorsModule，这样我就可以使用@inject而不是props：

public class ActorsModule extends AbstractModule implements AkkaGuiceSupport {
    @Override
    protected void configure() {
        bindActor(MainParser.class, "mainparser");

        Function<Props, Props> props = p -> SubPageParser.getProps();
        bindActor(SubPageParser.class, "subPageParser", props);
    }
}

更新：我已经修改为使用RoundRobinPool。然而，这并不像预期的那样有效。我指定了3作为实例数，但我为IF中的每个解析请求获取一个新对象。

Answer 1

像您所做的那样注入actor将导致每个mainparser有一个subpageParser。虽然您可以向它发送1000封邮件（使用tell)，但这些邮件将被逐个处理，而其他邮件则在邮箱中等待处理。

关于您的设计，您需要知道，像这样注入一个参与者将创建另一个顶级参与者，而不是创建subpageParser作为子参与者，这将允许父参与者控制和监视它。playframework支持注入子角色，如其文档所述:https://www.playframework.com/documentation/2.6.x/javaakka#dependency-injecting-child-actors

虽然你可以让akka使用一定数量的子演员来分配负载，但我认为你应该质疑为什么你一开始就使用演员。大多数问题都可以用简单的future来解决。例如，您可以配置一个自定义线程池来运行您的未来线程池，并让它们在您希望的并行化级别上完成工作:https://www.playframework.com/documentation/2.6.x/threadpools#using-other-thread-pools