专利名称：一种Java EE应用服务器并发处理方法
技术领域：
本发明涉及一种Java EE应用服务器并发处理方法，属于软件技术领域。
技术背景Java EE (Java Enterprise Environment)是Sun公司提出的基于Java的分布式应用的标 准平台，它通过提供企业计算环境所必需的各种服务，使得部署在Java EE平台上的基于 构件的分布式应用可以实现高可用性、安全性、可扩展性和可靠性等特征，是目前应用最 为广泛的面向Web的应用系统结构规范。它为Web应用的开发、部署、运行和管理提供 一系列的规范和标准。Java EE应用服务器通过容器来支持分层体系结构，容器提供了对Java EE应用组件的 运行时支持。图l显示了基于JavaEE平台的Web应用服务器的基本组成结构，其中Web 容器封装了 Web服务器与表示层逻辑的功能，为JavaEE表示层组件(如Servlet)提供了 运行时环境支持。EJB容器(Enterprise Java Bean Container)封装了业务层功能，为Java EE 业务层组件(EJB)提供运行时环境支持。同时，JavaEE应用服务器还提供了一系列的底 层服务(如Java消息服务、Java连接器体系结构、Java数据库连接服务等)为Web容器 和EJB容器提供一些底层功能支持，使其能够访问企业数据库与企业遗留系统，同时与其 他中间件交互(如消息中间件等)。对Java EE应用服务器而言，它必须能够同时为多个企业客户提供服务，这种并发处 理能力由其并发处理模型通过管理线程资源加以实现。目前的Java EE应用服务器采用的 并发处理模型主要是线程池模型，它为每个客户请求分配一个线程资源完成其处理，在轻 负载的情况下具有较好的性能表现。然而，在Java EE应用服务器中除了线程资源之外还包含大量的共享资源(如数据库 连接、Java消息队列等)，它们同样是完成客户请求处理所必须的资源。当JavaEE应用 服务器面临重负载时，共享资源不足会造成线程资源阻塞等待，直到获得相应的共享资源 后才能继续对客户请求的处理，在等待过程中，该线程实际上处于阻塞状态。当负载增大 时，将造成大量处理线程的阻塞，使得JavaEE应用服务器进入饱和状态，无法处理后续的请求，即使该请求并不需要造成线程阻塞的共享资源。可见，采用这种模式在负载较大 时对线程的使用效率较低，从而导致整个应用服务器的效率较低。通过监控共享资源的使用情况指导线程资源的管理能够有效的减少上述线程阻塞，提 高线程资源的利用率，进而提高JavaEE应用服务器的并发处理能力。发明内容针对上述现有Java EE应用服务器并发处理模型存在的问题和不足，本发明的目的是 提供一种共享资源敏感的Java EE应用服务器并发处理方法，提高Java EE应用服务器的 并发处理能力，使其能够同时为更多的企业客户提供服务。在本发明方法中，客户请求被 包装为请求事件，通过多个请求处理单元(Request Processing Unit, RPU)依次处理该请 求事件，各个请求处理单元完成请求处理的部分功能，并根据共享资源的使用情况为需要 处理的客户请求分配线程资源。本发明方法主要包括以下几个要素请求事件、资源上下文与请求处理单元(如图2 所示)。下面对这些要素作详细介绍(1) 请求事件在本发明方法中，请求事件是客户请求的内部表示，是请求处理单元的处理对象。通常情况下，请求事件包含了客户请求的所有信息。例如，在基于本发明方法实现的Web 容器中，请求事件包含了客户请求的URL、请求参数值、内部的会话对象引用等内容。(2) 资源上下文资源上下文定义了请求处理单元的共享资源需求，同时规定了对共享资源的一些使用 限制，是请求处理单元分配处理资源的依据。当一个请求事件到达请求处理单元后，假如 系统中仍存在空闲的共享资源并且当前请求处理单元使用的共享资源没有超过预定义的 资源限额，则请求处理单元为该请求事件分配一个处理资源执行请求处理逻辑。对JavaEE应用服务器而言，应用组件由Web应用开发者开发，Web容器无法事先获知 其共享资源需求。因此，资源上下文的定义需要Web应用开发者的参与，通过配置文件的 方式与应用组件一起部署到Web容器。下面给出了一个资源上下文的例子，指明了请求处 理单元Search需要类型为AppConnection的资源，最大使用数量为15。<ResourceContext><RPU〉Search</RPU> <Resources>〈Resource name=，，AppConnection，， max=，，15，，/> </Resources> </ResourceContext>(2)请求处理单元请求处理单元是本发明方法的核心组件，它将一系列请求处理步骤封装为请求处理任 务。同时，请求处理单元根据共享资源的使用情况为请求处理任务分配处理资源，完成请 求处理逻辑。下面首先详细介绍了组成请求处理单元的组件，然后给出了请求处理单元的 运行原理。*组成结构组成请求处理单元的组件如图3所示。 一个请求处理单元由输入事件队列(Input Event Queue)、调度器(Scheduler)、资源管理器(Resource Manager)、事件处理器(Event Handler)、 任务管理器(TaskManager)、分发器(Dispatcher)组成，下面将详细介绍每个组件的具 体功能。(1) 输入事件队列(Input Event Queue)。输入事件队列存储了所有当前请求处理单元需要处理的请求事件。在请求处理单元 内部，允许对请求事件的批量处理，这使得事件处理器能够在一个已经获得共享资 源的线程内批量处理事件，减少线程的上下文切换。(2) 事件处理器(Event Handler)。 每个请求处理单元包含一个事件处理器，它封装了当前请求事件处理流程的一个或 多个处理步骤，通常对应一些请求处理组件的处理逻辑，如解析HTTP请求为内部 请求对象。(3) 资源管理器(Resource Manager)。 资源管理器负责管理资源上下文并监控共享资源的使用情况，作为调度器线程创建 处理任务的依据。(4) 任务管理器(Task Manager)。任务管理器负责为请求事件创建处理任务。当请求事件的共享资源需求被满足时， 调度器线程创建一个处理任务并交给任务管理器，由任务管理器为其分配线程资源 以执行事件处理器封装的请求处理逻辑。(5) 分发器(Dispatcher)。 事件分发器负责将处理后的请求事件根据其类型分发到其他请求处理单元的输入 事件队列中，驱动请求处理流程的继续执行。(6) 调度器线程(Scheduler)。调度器线程是请求处理单元的核心，它拥有一个处理资源。它通过资源管理器监控 共享资源的使用情况，并为满足共享资源需求的请求事件创建处理任务交给任务管 理器执行。图4说明了调度器的状态转换图。1) 开始的时候调度器处于空闲状态(idle)。2) 当请求事件到达时，调度器通过资源管理器查看共享资源的使用情况。如果没有空闲的贡献资源，调度器进入资源阻塞状态(Resources blocked)。3) 当共享资源满足后资源管理器唤醒调度器进入活动状态(active)，此时调度器为请求事件创建处理任务并交给任务管理器，由其分配线程 资源，然后调度器线程回到空闲状态，继续等待后续事件的到来。* 运行原理请求事件在请求处理单元中的处理涉及多个组件，图5说明了请求事件在请求处理单 元中的处理过程。1) 当请求事件进入事件队列时，通知调度器存在请求事件需要处理；2) 调度器通过资源管理器査看是否存在空闲的共享资源，若不存在则调度器线程等待;3) 资源管理器通知调度器已经有共享资源释放，可以处理请求事件；4) 调度器从事件队列取出一批请求事件；5) 调度器创建处理任务；6) 调度器将请求处理任务交给任务管理器；7) 任务管理器为任务分配线程资源；8) 获得线程资源的任务调用事件处理器的处理逻辑处理事件；9) 分发器将处理后的请求事件分发到其他请求处理单元。本发明提出一种共享资源敏感的JavaEE应用服务器并发处理方法，和现有技术相比， 本发明方法的技术效果主要为-1. 本发明方法通过引入请求事件来解耦客户请求与线程资源的一一对应关系，使得 每个请求处理单元能够根据共享资源的使用情况为请求事件分配处理资源，超过 处理能力的请求事件在请求事件队列中等待，仅阻塞调度器线程。减少了因共享 资源竞争引起的线程资源阻塞，提高了Java EE应用服务器的并发处理能力。2. 本发明方法将客户请求的处理逻辑隔离在不同的请求处理单元中，每个请求处理 单元仅关心自己接收和产生的请求事件，这提供了一种灵活的组装方式，使得调 试和性能分析更加方便，监控代码能够方便的放在每个请求处理单元的入口和出 口来监控每个请求处理单元的性能，有利于性能瓶颈的定位。
图l是Web应用服务器的基本组成结构图2是本发明方法涉及的基本组成组件图3是请求处理单元组件组成示意4是调度器线程的状态5是请求事件处理的UML顺序6是Once Web Container的请求处理流程图7是Once Web容器的请求处理流程图8是按照本发明方法与线程池方法分别设计的Web容器性能比较具体实施方式
以下结合具体实施例和附图对本发明作更详细的说明。在OnceWebContainer中， 一个客户请求的处理过程分为18个步骤(如图6所示)，涉及六个请求处理组件，分别为监听器组件(HTTPListener)、服务器组件(DefaultServer)、 虚拟主机组件(DefaultHost)、上下文组件(DefaultContext)、外壳组件(DefaultShell) 以及Servlet组件，其中HTTPListener负责监听端口， DefaultServer、 DefaultHost、 DefaultContext、 DefaultShell分别对应Web容器本身、虛拟主机、Web应用以及一个Servlet 的内部表示，Servlet代表应用开发者开发的实际应用组件实例。请求处理过程每个步骤的具体含义如下1) accept,由HTTPListener组件接收客户端的请求，创建套接字对象(socket)。2) notifyThread，当前的领导者线程通知线程池中的另一个线程成为领导者，当前线程 作为处理线程继续处理客户请求3) handle,调用DefaultServer进行处理4) parseRequest， DefaultServer从socket的输入流中解析HTTP请求5) parseHeader, DefaultServer从socket中解析HTTP头信息6) createRequest， DefaultServer创建Web容器的内部request对象7) createResponse, DefaultServer创建Web容器的内部response对象8) service, DefaultServer将请求交给DefaultHost处理9) map, DefaultHost将请求映射到对应的DefaultContext10) service， DefaultHost将请求交给对应的DefaultContext处理11) map, DefaultContext将请求映射到对应的DefaultShell，即Servlet在Web容器内部的代表12) service, DefaultContext将请求交给DefaultShell处理13) createFilter，创建对应Servlet的过滤器(Filter)14) doFilter，调用对应的过滤器逻辑15) service,调用具体Servlet实例的service方法，完成业务逻辑处理16) return,处理结果返回给DefaultServer17) prepareHeaders， DefaultServer生成HTTP响应头信息18) sendResponse, DefaultServer将处理结果返回给客户端在以上请求处理过程中，步骤l、 2负责接收客户请求，获得对应的套接字对象。步骤 4-7负责从套接字对象的输入流中读入数据，并按照HTTP协议将其解析为服务器的内部请 求对象。步骤8-16负责将请求对象映射到对应的Servlet，并由对应的Servlet处理客户请求。最后，步骤17-18将处理结果包装为HTTP响应对象返回给客户端。假设当前的Web应用包含三个Servlet:管理员请求(Admin Request)、首页信息(Home) 和搜索请求(Search)，则每个Servlet的处理流程都对应图6的请求处理过程，所不同的是 它们具有不同的Servlet实例。按照本发明所述方法设计Web容器的请求处理流程如下1) 根据图6的功能叙述，请求处理流程被划分为5个请求处理单元，分别是HTTP 监听器请求处理单元(HTTPListener) 、 HTTP解析器请求处理单元(HTTPParser)、映射器请求处理单元(URLMapper) 、 Servlet方法请求处理 单元(ServletMethod)、响应发送器请求处理单元(ResponseSender)。2) 由于HTTPListener和ResponseSender需要套接字共享资源，因此保持它们作为独 立的请求处理单元，而HTTPParser与URLMapper不需要特别的共享资源，二者被合并为 一个请求处理单元。3) 三个Servlet中，Home不需要线程资源之外的共享资源。Admin Request和Search 需要数据库连接共享资源以完成对数据库的査找，同时AdminRequest还需要安 全数据库连接资源以完成对管理员身份的认证。因此，每个具体的Servlet都对 应一个请求处理单元，这样使得每个Servlet可以根据其共享资源需求来为请求 分配线程资源。4) 最终得到的请求处理流程如图7所示，请求处理流程包含6个请求处理单元 HTTPListener、 HTTPParser& URLMapper、 Response Sender、 Admin Request、 Home与Search,为了更具体地比较根据本发明方法设计的Web容器和现有的Web容器在性能上的差 异，本实施例使用TPC-W基准测试程序作为比较标准，该测试程序由事务处理性能委员会 (Transaction Processing Performance Council, TPC)在2000年推出，代表一个典型的电子 商务应用环境，模拟了一个有大量并发的访问者的网上书店系统。TPC-W模拟了客户的以下行为完成购物并使用购物车，在存货表中做搜索，填写客户信息，执行商店管理的职责，买购物车里的商品，査询最佳售货员和新商品列表，询问以前的订单情况等。同时，TPC-W还提供了以上客户行为的三种组成混合类型浏览类型(Browsing)、购买类型 (Shopping)以及订购类型(Ordering)。图8显示了基于线程池模型设计的Web容器与基 于本发明方法设计的Web容器的性能比较结果，可以看出，在不同的访问模式下，本发明的并发处理方法都取得了更好的性能。下面给出了有关请求事件、资源上下文以及请求处理单元接口的部分实现代码以更好 地说明本实施例方法public interface Event { public String getType(); public String getDescription(); public void setDirection(boolean direction); public boolean getDirection(); public Object getProducter(); public Request getRequest(); public Response getResponse(); public void setRequest(Request request); public void setResponse(Response response); public void setSocket(Socket socket); public Socket getSocket(); public InputStream getInputStream(); public OutputStream getOutputStreamO; public void setInputStream(InputStream is); public void setOutputStream(OutputStream os);public interface RPU {public String getName(); public void setName(》public void setEventQueue(Queue<Event> q); public Queue<Event> getEventQueue(); public ResourceContext getResourceContext(); public void setResourceContext(ResourceContext rc); public void setDispatcher(Dispatcher dis); public Dispatcher getDispatcher();public interface ResourceContext { public int getType(); public String getName(); public int getMaxSize(); public int setMaxSize(); public int getAvaiable();具体请求处理单元内部的调度器与处理任务代码如下-class Scheduler implements Runnable{public void run() { while(true){Event clientEvent = queue.poll(); if(dientEvent != null)(Task task = new Task(clientEvent); TaskManager.execw^ros^(task);class Task {public Event clientEvent = null; public Task(ClientEvent clientEvent) { this.clientEvent = clientEvent;public void run() { try {forwardRequest(clientEvent); } catch (ServletException e) {e .printStackTrace(); } catch (IOException e) {e.printStackTrace();
权利要求
1.一种Java EE应用服务器并发处理方法，其特征在于，所述应用服务器包括一个或多个请求处理单元，各个请求事件依次通过所述请求处理单元中的一个或多个进行处理；各个请求处理单元在处理所述请求事件之前查看是否存在处理该请求事件所需的空闲的共享资源，若是，则为当前请求处理单元分配线程并处理所述请求事件，若否，则不为当前请求处理单元分配线程并等待，直至出现所需的空闲的共享资源。
2. 如权利要求l所述的方法，其特征在于，在各个请求处理单元中，仅在处理过程中需 要共享资源的请求处理单元在处理所述请求事件之前査看是否存在处理该请求事件所需的空闲的共享资源。
3. 如权利要求1所述的方法，其特征在于，所述一个或多个请求处理单元实现互不相同 的处理功能。
4. 如权利要求1所述的方法，其特征在于，为当前请求处理单元分配线程前还检验当前 请求处理单元所需的共享资源是否超过预定义的资源限额，若否，则为其分配线程。
5. 如权利要求1所述的方法，其特征在于，所述请求处理单元在同一线程内批量处理该 请求处理单元内待处理的请求事件。
6. 如权利要求1到5任意一项所述的方法，其特征在于，所述请求处理单元由输入事件 队列、调度器、资源管理器、事件处理器、任务管理器和分发器组成；所述输入事件队列存储所有当前请求处理单元需要处理的请求事件；所述调度器通过资源管理器监控共享资源的使用情况，并为满足共享资源需求的请求 事件创建处理任务交给任务管理器；所述资源管理器管理资源上下文并监控共享资源的使用情况，作为调度器线程创建处 理任务的依据；所述事件处理器对应请求处理组件的处理逻辑，完成其处理功能； 所述任务管理器负责为请求事件创建处理任务；所述分发器负责将处理后的请求事件根据其类型分发到其他请求处理单元的输入事 件队列中，驱动请求处理流程的继续执行。
7. 如权利要求6所述的方法，其特征在于，所述请求处理单元的处理过程包括下列步骤:a) 请求事件进入所述事件队列，通知所述调度器存在请求事件需要处理；b) 所述调度器通过所述资源管理器查看是否存在空闲的共享资源，若不存在则调度 器线程等待；c) 所述资源管理器通知所述调度器己经有共享资源释放，可以处理请求事件；d) 所述调度器从事件队列中取出一批请求事件；e) 所述调度器创建处理任务；f) 所述调度器将请求处理任务交给所述任务管理器；g) 所述任务管理器为任务分配线程资源；h) 获得线程资源的任务调用所述事件处理器的处理逻辑处理事件;i) 所述分发器将处理后的请求事件分发到其他请求处理单元。
全文摘要
本发明公开了一种Java EE应用服务器并发处理方法，属于软件技术领域。本发明所述应用服务器包括一个或多个请求处理单元，各个请求事件依次通过所述请求处理单元中的一个或多个进行处理；各个请求处理单元在处理所述请求事件之前查看是否存在处理该请求事件所需的空闲的共享资源，若是，则为当前请求处理单元分配线程并处理所述请求事件，若否，则不为当前请求处理单元分配线程并等待，直至出现所需的空闲的共享资源。和现有技术相比，本发明方法减少了因共享资源竞争引起的线程资源阻塞，提高了Java EE应用服务器的并发处理能力，同时使得调试和性能分析更加方便，有利于性能瓶颈的定位。
文档编号G06F9/50GK101334742SQ200810117820
公开日2008年12月31日 申请日期2008年8月5日 优先权日2008年8月5日
发明者张文博, 洋 李, 华 钟, 峻 魏, 涛 黄 申请人:中国科学院软件研究所