EJB 3.1 异步方法和线程池

Question

我每天需要使用 EJB 3.1 异步方法处理大约 250.000 个文档，才能完成一项长期任务。

我这样做是为了使用更多线程并同时处理更多文档。下面是一个伪代码示例：

// this returns about 250.000 documents per day
List<Document> documentList = Persistence.listDocumentsToProcess();

for(Document currentDocument: documentList){
      //this is the asynchronous call
      ejbInstance.processAsynchronously(currentDocument);
}

假设我有一个大小为 10 和 4 个核心处理器的线程池，我的问题是：

• 应用程序服务器将同时处理多少个文档？
• 当池中的所有线程都在处理一个文档并且又来一个异步调用时会发生什么？这会像 JMS 队列一样工作吗？
• 如果采用 JMS 队列解决方案，我有什么改进吗？

我使用 Java EE 6 和 WebSphere 8.5.5.2

Answer 1

异步 ​​EJB 方法调用的默认配置如下（来自信息中心）：

EJB 容器工作管理器具有以下线程池设置：

Minimum number of threads = 1
Maximum number of threads = 5
Work request queue size = 0 work objects
Work request queue full action = Block
Remote Future object duration = 86400 seconds

所以尝试回答您的问题：
应用程序服务器将同时处理多少个文档？ （假设 10 大小的线程池）

此线程池用于所有 EJB 异步调用，因此首先您需要假设您的应用程序是唯一使用 EJB 异步调用的应用程序。然后，您可能会有 10 个 runnable 实例，它们将被并行处理。它们是否会同时处理取决于系统中可用的核心/线程的数量，因此您无法获得准确的数量（例如，某些核心/线程可能正在执行 Web 工作，或者其他使用 cpu 的进程)。

当池中的所有线程都在处理一个文档并且又来一个异步调用时会发生什么？
这取决于Work request queue size 和Work request queue full action 设置。如果池中没有可用线程，则请求将排队，直到达到队列大小。然后取决于操作，可能是Block 或Fail。

如果采用 JMS Queue 解决方案，我会有什么改进吗
取决于你的需要。以下是 JMS 解决方案的一些优缺点。
优点：

• 持久性 - 如果使用 JMS，您的异步任务可以是持久性的，因此在服务器故障的情况下您不会丢失它们，并且将在重新启动后或由其他集群成员处理。 EJB 异步队列仅保存在内存中，因此队列中的任务会在失败时丢失。
• 可扩展性 - 如果将任务放入队列，它们可能会被集群中的许多服务器同时处理，而不仅限于单个 JVM
• 过期和优先级 - 您可以为消息定义不同的过期时间或优先级。

缺点：

• 更复杂的应用程序 - 您需要实施 MDB 来处理您的任务。
• 更复杂的基础架构 - 您将需要数据库来存储队列（文件系统可用于单个服务器，共享文件系统可用于集群），或 WebSphere MQ 等外部消息传递解决方案
• 处理单个项目的性能稍低，服务器负载较高，因为必须将其序列化/反序列化为持久存储