Tomcat的管道

Tomcat中按照包含关系一共有四个容器——StandardEngine、StandardHost、StandardContext和StandardWrapper,对这四个容器的详细解析后面会涉及,请求对象及响应对象将分别被此四个容器处理,请求响应对象在四个容器之间通过管道机制进行传递。如下图,请求响应对象先通过StandardEngine的管道,期间经过若干个阀门处理,基础阀门是StandardEngineValve;往下流转到StandardHost的管道,基础阀门为StandardHostValve;类似地通过StandardContext;最后到StandardWrapper完成整个处理流程。

这种设计为每个容器都带来了灵活的机制,可以按照需要对不同容器添加自定义阀门进行不同的逻辑处理,并且tomcat将管道机制做成可配置形式,对于存在的阀门只需通过配置文件即可,还可以自定义阀门并配置就可在相应作用域内生效。四个容器中每个容器都包含自己的管道对象,管道对象用于存放若干阀门对象,他们都有自己的基础阀门,且基础阀门是tomcat默认设置的,一般不可更改之,以免运行时产生问题。

下面分别看看这些基础阀门详细的解析

① StandardEngineValve,此阀门最重要的逻辑如下,调用时它会获取请求对应的主机host对象,同时负责调用host对象中管道的第一个阀门。

public final voidinvoke(Request request, Response response)

        throws IOException, ServletException {

        Host host = request.getHost();

       host.getPipeline().getFirst().invoke(request, response);

    }

 

② StandardHostValve,尽管包含了其他的处理逻辑,但不可缺少的逻辑是获取请求对应的上下文context对象并调用context对象中管道的第一个阀门。

public final voidinvoke(Request request, Response response)

        throws IOException, ServletException {

        Context context = request.getContext();

触发request初始化事件

        context.getPipeline().getFirst().invoke(request, response);

更新会话上次访问时间

    }

 

③ StandardContextValve,上下文基础阀门先会判断是否访问了禁止目录WEB-INF或META-INF,接着获取请求对应的wrapper对象,再向客户端发送通知报文“HTTP/1.1 100 Continue”,最后调用wrapper对象中管道的第一个阀门。

public final voidinvoke(Request request, Response response)

        throws IOException, ServletException {

判断访问路径是否包含WEB-INF或META-INF,禁止访问此目录

        Wrapper wrapper = request.getWrapper();

        向客户端发送"HTTP/1.1 100 Continue"通知

       wrapper.getPipeline().getFirst().invoke(request, response);

    }

 

④ StandardWrapperValve,包装器基础阀门负责统计请求次数、统计处理时间、分配Servlet内存、执行servlet过滤器、调用Servlet的service方法、释放Servlet内存。

public final voidinvoke(Request request, Response response)

        throws IOException, ServletException {

        统计请求次数

        StandardWrapper wrapper =(StandardWrapper) getContainer();

        Servlet servlet = wrapper.allocate();

        执行servlet的过滤器

        servlet.service(request, response);

        wrapper.deallocate(servlet);

        统计处理时间

    }

点击订购作者《Tomcat内核设计剖析》

时间: 2024-10-03 02:32:10

Tomcat的管道的相关文章

75篇关于Tomcat源码和机制的文章

整理下前面写过的75篇关于Tomcat源码和机制的文章 文章列表 如何设计一个Web容器 Web安全认证机制知多少 Tomcat集群实现源码级别剖析 Tomcat集群如何同步会话 从单机到集群会话的管理之集群模式一 从单机到集群会话的管理之集群模式二(更大的集群) Tomcat集群的failover机制 Tomcat集群应用部署的实现机制 Tomcat集群机制剖析及其生产部署选型 Tomcat如何实现WebSocket Tomcat如何实现Comet Tomcat怎么实现异步Servlet To

apt-cache 搜索软件

apt-cache search 搜索包 --names-only, -n 指定搜索名称:Only search on the package and provided package names, not the long descriptions. 1:apt-cache search -n 包名 2:apt-cache search ^tomcat 使用正则 表示以 tomcat 开头 3:apt-cache search tomcat| grep tomcat 使用管道过滤 删除软件并移

Tomcat的过滤诀窍

过滤是 Tomcat 4 的新功能.它是 Servlet 2.3 规范的一部分,并且最终将 为所有支持此标准的 J2EE 容器的厂商所采用执行.开发人员将能够用过滤器来 实现以前使用不便的或难以实现的功能,这些功能包括: 资源访问(Web 页.JSP 页.servlet)的定制身份认证 应用程序级的访问资源的审核和记录 应用程序范围内对资源的加密访问,它建立在定制的加密方案基础上 对被访问资源的及时转换,包括从 servlet 和 JSP 的动态输出 这个清单当然并没有一一罗列,但它让您初步体验

浅谈管道模型(Pipeline)

本篇和大家谈谈一种通用的设计与处理模型--Pipeline(管道). Pipeline简介 Pipeline模型最早被使用在Unix操作系统中.据称,如果说Unix是计算机文明中最伟大的发明,那么,Unix下的Pipe管道就是跟随Unix所带来的另一个伟大的发明[1].我认为管道的出现,所要解决的问题,还是软件设计中老生常谈的设计目标--高内聚,低耦合.它以一种"链式模型"来串接不同的程序或者不同的组件,让它们组成一条直线的工作流.这样给定一个完整的输入,经过各个组件的先后协同处理,得

深入理解Tomcat系列之五:Context容器和Wrapper容器

前言 Context容器是一个Web项目的代表,主要管理Servlet实例,在Tomcat中Servlet实例是以Wrapper出现的,现在问题是如何才能通过Context容器找到具体的Servlet呢?在解决这个问题之前,Context容器需要先启动,启动的过程就是加载个类资源文件以及打开子容器以及Pipeline管道的过程.启动Context容器后,就可以处理具体的请求了,具体是通过Request对象,从代码清单4-3的Wrapper wrapper = request.getWrapper

tomcat 性能优化(转)

  tomcat nginx默许的post大小限制 tomcat nginx默认的post大小限制执行大文件上传,或者,大数据量提交时,当提交的数据大小超过一定限制时,发现后台从request取值的代码request.getParameter("message")返回值为null,原因是因为服务器对于提交的post请求的大小有一定的限制 tomcat:默认大小2097152,当maxPostSize=0时,不限制:maxPostSize=20971520时,为20Mnginx:默认的最

Tomcat如何实现资源安全管理

在了解了认证模式及Realm域后,我们看看Tomcat是如何设计实现资源安全管理的.在认证模式上,必须要支持多种认证模式,包括Basic模式.Digest模式.Form模式.Spnego模式.SSL模式及NonLogin模式.如何实现这些认证模式比较优雅,或者说比较清晰?看下图,在tomcat中一个请求从浏览器发送过来后,请求接收后会流向四个级别容器处理,即Engine->Host->Context->Wrapper,而且是以管道阀门(pipeline和valve)形式进行处理,只需往某

深入理解Tomcat系列之四:Engine和Host容器

前言 终于到Container容器了,上面说到Connector把封装了Request对象以及Response对象的Socket传递给了Container容器,那么在Contianer容器中又是怎么样的处理流程呢?在说Container容器之前,有必要对Container容器有一个简单的了解,Container容器是子容器的父接口,所有的子容器都必须实现这个接口,在Tomcat中Container容器的设计是典型的责任链设计模式,其有四个子容器:Engine.Host.Context和Wrapp

tomcat 性能优化

tomcat默认参数是为开发环境制定,而非适合生产环境,尤其是内存和线程的配置,默认都很低,容易成为性能瓶颈. tomcat内存优化 linux修改TOMCAT_HOME/bin/catalina.sh,在前面加入 JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai" windows修改TOMCAT_HOME/bin/catalina.bat,