EJB 3.1的异步方法和线程池 [英] EJB 3.1 asynchronous method and thread pool

问题描述

我需要每天处理约250.000文件与EJB 3.1异步方法，以面对整体很长一段时间的工作。

我这样做是为了使用多个线程和处理更多并发的文件。下面是伪code的例子：

  //这将返回每天约250.000文件
清单＆lt;文件＆GT; documentList = Persistence.listDocumentsToProcess（）;对于（文件currentDocument：documentList）{
      //这是异步调用
      ejbInstance.processAsynchronously（currentDocument）;
}
 

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

• 有多少文件，将应用服务器同时处理？


• 当池中的所有线程正在处理的文件和一个更异步调用来发生什么？将这项工作就像一种JMS队列？
的

• 我会采用JMS队列解决任何改进

我与Java EE 6和WebSphere 8.5.5.2工作

解决方案

异步EJB方法的默认配置要求如下（从信息中心）：

  

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

 线程= 1的最小数量
最大线程数= 5
工作请求队列的大小= 0的工作对象
工作请求队列满操作=块
遥远的未来目标持续时间=86400秒
 

所以，试图为您解答：结果
有多少文件，将应用程序服务器进程能兼得吗？ （假设10大小的线程池）的

这线程池是所有EJB异步调用，所以首先你需要假设你的应用程序是使用EJB异步调用的唯一的一个。然后，你将可能有10的可运行的的情况下，将在并行处理。他们是否会被处理的同时的取决于系统中可用的核心/线程数，所以你不能有准确的数字（一些核心/线程可能会做网页的工作，例如，或者使用CPU的其他工艺）。

什么时，在池中的所有线程正在处理一个文档和多了一个异步调用自带发生？的结果
这取决于工作请求队列大小和工作请求队列满行动，设置。如果在池中没有可用的线程，则请求将被直到达到队列大小排队。然后，它取决于行动，这可能是阻止或失败。

我会采用JMS队列解决任何改进的结果
取决于你的需要。这里有一些优点/缺点JMS解决方案。结果
优点：

• 持久性 - 如果使用JMS的异步任务可以持久的，所以你不会失去了他们的服务器发生故障的情况下，并重新启动后，或通过其他群集成员将被处理。 EJB异步队列被保持只在内存中，所以在队列任务失败的情况下都将丢失。


• 可扩展性 - 如果你把任务队列中，他们可能会并发集群中的多台服务器进行处理，而不是仅限于单个JVM


• 到期和优先级 - 您可以定义不同的到期时间或优先邮件
。

缺点：

• 更复杂的应用程序 - 你将需要实现MDB处理您的任务
。

• 更复杂的基础设施 - 你需要数据库来存储队列（文件系统可用于单个服务器，并且共享文件系统，可用于群集），或类似的WebSphere MQ外部消息溶液


• 处理服务器上的单项和更高的负载，因为它必须被序列化/反序列化到永久存储有点低性能

I need to process about 250.000 documents per day with an EJB 3.1 asynchronous method in order to face an overall long time task.

I do this to use more threads and process more documents concurrently. Here's an example in pseudo code:

// 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);
}

Suppose I have a thread pool of size 10 and 4 core processors, my questions are:

• how many documents will the application server process SIMULTANEOUSLY?
• what happen when all thread in pool are processing a documents and one more asynchronous call comes? Will this work like a sort of JMS Queue?
• would I have any improvement adopting a JMS Queue solution

I work with Java EE 6 and WebSphere 8.5.5.2

解决方案

The default configuration for asynchronous EJB method calls is as follows (from the infocenter):

The EJB container work manager has the following thread pool settings:

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

So trying to answer your questions:
how many documents will the application server process SIMULTANEOUSLY? (assuming 10 size thread pool)

This thread pool is for all EJB async calls, so first you need to assume that your application is the only one using EJB async calls. Then you will potentially have 10 runnable instances, that will be processed in parallel. Whether they will be processed concurrently depends on the number of cores/threads available in the system, so you cant have accurate number (some cores/threads may be doing web work for example, or other process using cpu).

what happen when all thread in pool are processing a documents and one more asynchronous call comes?
It depends on the Work request queue size and Work request queue full action, settings. If there are no available threads in the pool, then requests will be queued till the queue size is reached. Then it depends on the action, which might be Block or Fail.

would I have any improvement adopting a JMS Queue solution
Depends on your needs. Here are some pros/cons JMS solution.
Pros:

• Persistence - if using JMS your asynchronous task can be persistent, so in case of the server failure you will not lost them, and will be processed after restart or by other cluster member. EJB async queue is held only in memory, so tasks in queue are lost in case of failure.
• Scalability - if you put tasks to the queue, they might be concurrently processed by many servers in the cluster, not limited to single JVM
• Expiration and priorities - you can define different expiration time or priorities for your messages.

Cons:

• More complex application - you will need to implement MDB to process your tasks.
• More complex infrastructure - you will need database to store the queues (file system can be used for single server, and shared filesystem can be used for clusters), or external messaging solution like WebSphere MQ
• a bit lower performance for processing single item and higher load on server, as it will have to be serialized/deserialized to persistent storage

这篇关于EJB 3.1的异步方法和线程池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！