EJB 3.1的异步方法和线程池

问题描述

我需要每天处理约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方法的默认配置要求如下（从信息中心）：

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的异步方法和线程池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！