无响应的执行元系统：ThreadPoolExecutor调度器只创建核心线程池，显然忽略了最大线程池大小

Question

null

{"akka" : { "actor" : { "default-dispatcher" : {
    "type" : "Dispatcher",
    "executor" : "default-executor",
    "throughput" : "1",
    "default-executor" : { "fallback" : "thread-pool-executor" }
    "thread-pool-executor" : {
        "keep-alive-time" : "60s",
        "core-pool-size-min" : coreActorCount,
        "core-pool-size-max" : coreActorCount,
        "max-pool-size-min" : maxActorCount,
        "max-pool-size-max" : maxActorCount,
        "task-queue-size" : "-1",
        "task-queue-type" : "linked",
        "allow-core-timeout" : "on"
}}}}}

其他地方配置了工人数，当前workercount=8；CoreActorCount是WorkerCount+3而MaxActorCount是WorkerCount*3+5。我在一台拥有两个核心和8GB内存的Macbook Pro 10上测试这一点；生产服务器要大得多。我正在与之交谈的数据库背后是一个速度极慢的VPN。我使用Oracle的Javase1.8JVM运行所有这些。本地服务器是Tomcat7。Oracle JDBC驱动程序是10.2版（我也许能够说服那些使用较新版本的能力）。所有方法要么返回void要么返回future<>并且应该是非阻塞的。

当一个批处理成功终止时，就没有问题了--下一个批处理立即开始，并满员。但是，如果我通过JobManager#Completion.TryFailure（新的CancellationException（“批处理已取消”）)终止当前批处理，则Workers注册的OnFailure回调会触发，然后系统变得没有响应。调试打印指示新批处理从八个正常工作的工作者中的三个开始，并且BatchManager变得完全没有响应（我添加了一个future ping 命令，该命令只返回一个future.successful（“ping”），并且也会超时）。onfailure回调在单独的线程池上执行，即使它们在执行元系统的线程池上，我也应该有足够高的max-pool-size以容纳原始的JobManager、它的workers、它的onfailure回调，以及第二个JobManager和是workers。相反，我似乎可以容纳原始的JobManager及其Workers、新的JobManager及其不到一半的Workers以及BatchManager。我正在运行的计算机资源不足，但似乎应该能够运行十几个线程。

这是配置问题吗？这是由于JVM施加的限制和/或Tomcat施加的限制造成的吗？这是由于我处理阻塞IO的方式有问题吗？可能还有其他几件事我可能做错了，这些就是我想到的。

CancellableStatement的要点，其中CallableStatement和OracleConnection被取消

创建cancellablestatements时的不可变要点

编辑：我相信我已经将问题缩小到了actor系统（或者是它的配置，或者是它与阻塞数据库调用的交互）。我消除了worker执行元，并将其工作负载移到在固定大小的ThreadPoolExecutor上执行的Runnable，其中每个JobManager创建自己的ThreadPoolExecutor并在批处理完成时关闭它（正常终止时Shutdown；异常终止时ShutdownNow)。取消在BatchManager中实例化的缓存线程池上运行。actor系统的调度器仍然是ThreadPoolExecutor，但只分配了六个线程。使用此替代设置，取消将按预期执行-当终止其数据库连接时，工作程序终止，新的JobManager立即执行，并使用完整的工作程序线程。这表明这不是硬件/JVM/Tomcat问题。

更新：我使用Eclipse的内存分析器进行了线程转储。我发现取消线程挂在CallableStatement.Close()上，因此我对取消重新排序，使OracleConnection.Abort()在CallableStatement.Cancel()之前，这就解决了问题--取消全部（显然）正确执行。虽然worker线程继续挂起它们的语句--我怀疑我的VPN可能部分或全部要为此负责。

PerformanceAsync-akka.actor.default-dispatcher-19
  at java.net.SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I (Native Method)
  at java.net.SocketInputStream.read([BIII)I (SocketInputStream.java:150)
  at java.net.SocketInputStream.read([BII)I (SocketInputStream.java:121)
  at oracle.net.ns.Packet.receive()V (Unknown Source)
  at oracle.net.ns.DataPacket.receive()V (Unknown Source)
  at oracle.net.ns.NetInputStream.getNextPacket()V (Unknown Source)
  at oracle.net.ns.NetInputStream.read([BII)I (Unknown Source)
  at oracle.net.ns.NetInputStream.read([B)I (Unknown Source)
  at oracle.net.ns.NetInputStream.read()I (Unknown Source)
  at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1()S (T4CMAREngine.java:1109)
  at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1()B (T4CMAREngine.java:1080)
  at oracle.jdbc.driver.T4C8Oall.receive()V (T4C8Oall.java:485)
  at oracle.jdbc.driver.T4CCallableStatement.doOall8(ZZZZ)V (T4CCallableStatement.java:218)
  at oracle.jdbc.driver.T4CCallableStatement.executeForRows(Z)V (T4CCallableStatement.java:971)
  at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout()V (OracleStatement.java:1192)
  at oracle.jdbc.driver.OraclePreparedStatement.executeInternal()I (OraclePreparedStatement.java:3415)
  at oracle.jdbc.driver.OraclePreparedStatement.execute()Z (OraclePreparedStatement.java:3521)
  at oracle.jdbc.driver.OracleCallableStatement.execute()Z (OracleCallableStatement.java:4612)
  at com.util.CPProcExecutor.execute(Loracle/jdbc/OracleConnection;Ljava/sql/CallableStatement;Lcom/controller/BaseJobRequest;)V (CPProcExecutor.java:57)

然而，即使在修复了取消顺序之后，我仍然存在actor系统没有创建足够的线程的问题：在新批处理中，我仍然只能获得8个工作者中的3个，并且由于被取消的工作者的网络连接超时，还会添加新的工作者。总共我有11个线程--我的核心池大小，在29个线程中--我的最大池大小。显然，执行元系统忽略了我的最大池大小参数，或者我没有正确配置最大池大小。

Answer 1

（免责声明：我不认识Akka）

根据您下面的queue-size=-1配置，我猜任务队列是无界的。

  "task-queue-size": "-1",
  "task-queue-type": "linked"

除非工作队列已满且无法排队，否则ThreadPoolExecutor不会生成超出核心池大小的内容。只有当任务队列已满时，它才会开始生成最多的线程。