Tomcat容器结构及Pipeline机制

我们到底能走多远系列(13)

扯淡:

  有机会有时间的话,我是会看那个职来职往的电视节目,个人觉得比其他一些娱乐节目对自己有帮助一些,我主要关注的还是现在人们的价值观,因为只有了解别人的价值观,也就是别人想要的,才可以更好的和他们沟通交流,从而达到目的。想必大家都听过,励志牛人说过:想要别人给你想要的,谈论他想要的。

  有时候,“慎言”是很好的习惯,多聆听,多观察,就像《闻香识女人》中的台词一样:day we stop looking, is the day we die.

主题:

  直接学习tomcat的valve好像有点突兀,所以还是先去了解下tomcat的一个核心的组件containercontainer从上一个组件connector手上接过解析好的内部request,根据request来进行一系列的逻辑操作,直到调用到请求的servlet,然后组装好response,返回给clint。  整个大流程还是清晰明了的。毕竟我们大概了解了tomcat的输入和输出也能猜出它里面的一些必要的操作。

先来看看container的分类吧:EngineHostContextWrapper它们各自的实现类分别是StandardEngine, StandardHost, StandardContext, and StandardWrapper,他们都在tomcat的org.apache.catalina.core包下。

它们之间的关系,可以查看tomcat的server.xml也能明白(根据节点父子关系),这么比喻吧:除了Wrapper最小,不能包含其他container外,Context内可以有零或多个Wrapper,Host可以拥有零或多个Host,Engine可以有零到多个Host。

在tomcat6里这些Standard 的 container都是直接继承抽象类:org.apache.catalina.core.ContainerBase:

从ContainerBase这个类中的一些方法名我们可以看到各个container之间包含和被包含的操作是如何实现的,这些都是他提供的方法:

public void addChild(Container child)public Container findChild(String name)public Container[] findChildren()public ObjectName[] getChildren()public Container getParent()public ObjectName getParentName()public void removeChild(Container child)

当然一个container的实现是复杂的,先跳过,未来定有机会回来学习的。

Pipeline的机制:

它的结构和实现是非常值得我们学习和借鉴的。

来看看来自网络的流程图(很不错的图):

多好的图啊,单看图你就可以了解大概的tomcat运行的情况了,哈哈。

首先要了解的是每一种container都有一个自己的StandardValve上面四个container对应的四个是:StandardEngineValveStandardContextValveStandardHostValveStandardWrapperValve

有人把vavle比作filter,而Pipeline比作filter chain,网站空间,其实已经很恰当了。这里就说下我的理解:

开端:在CoyoteAdapter的service方法里,由下面这一句就进入Container的。connector.getContainer().getPipeline().getFirst().invoke(request, response); 是的,这就是进入container迷宫的大门,欢迎来到Container。

Pipeline(注意上面结构图的pipeline的连线):

Pipeline就像一个工厂中的生产线,负责调配工人(valve)的位置,valve则是生产线上负责不同操作的工人。一个生产线的完成需要两步:1,美国空间,把原料运到工人边上2,工人完成自己负责的部分而tomcat的Pipeline实现是这样的:1,在生产线上的第一个工人拿到生产原料后,二话不说就人给下一个工人,下一个工人模仿第一个工人那样扔给下一个工人,直到最后一个工人,而最后一个工人被安排为上面提过的StandardValve,他要完成的工作居然是把生产资料运给自己包含的container的Pipeline上去。2,四个container就相当于有四个生产线(Pipeline),四个Pipeline都这么干,香港空间,直到最后的StandardWrapperValve拿到资源开始调用servlet。完成后返回来,一步一步的valve按照刚才丢生产原料是的顺序的倒序一次执行。如此才完成了tomcat的Pipeline的机制。

结束:

所有的vavle执行完毕后,整个响应的也就结束了。

关于Pipeline我们来看下源码:

一个StandardValve

来自org.apache.catalina.core.StandardEngineValve的invoke方法:

invoke(Request request, Response response)throws IOException, ServletException {// 拿到自己包含的hostHost host = request.getHost();if (host == null) {response.sendError(HttpServletResponse.SC_BAD_REQUEST,sm.getString(“standardEngine.noHost”,request.getServerName()));return;}// 最为自己pipeline上最后一位工人,负责把原料运给系一个pipeline// 这是把所有pipeline串联起来的关键host.getPipeline().getFirst().invoke(request, response);}

一个普通的valve

来自org.apache.catalina.valves.ErrorReportValveinvoke方法:

public void invoke(Request request, Response response)throws IOException, ServletException {// 已经来就把原料丢给下一个vavle执行,这是把所有vavle串联成一个pipeline的关键getNext().invoke(request, response);// 等到上面的valve全部执行好,才开始自己的真正工作:Throwable throwable =(Throwable) request.getAttribute(Globals.EXCEPTION_ATTR);if (response.isCommitted()) {return;}if (throwable != null) {// The response is an errorresponse.setError(); {response.reset();} catch (IllegalStateException e) {;}response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);}response.setSuspended(false);try {report(request, response, throwable);} catch (Throwable tt) {;}}

以上就描述了Pipeline机制,不知道你是不是会疑问(反正我是有了):vavle是在servlet前执行还是后执行,看上面源码的例子好像是在后执行哦? 其实是不一定的,以RemoteAddrValve为例子:

RemoteAddrValve可以根据ip地址限制访问,这个在文章后面附上了一些来自网络的配置步骤。

RemoteAddrValve源码:

青春一经典当即永不再赎

Tomcat容器结构及Pipeline机制

相关文章:

你感兴趣的文章:

标签云: