Tomcat 管道与阀
作者:互联网
以下部分内容摘抄自《深入剖析Tomcat》,该书籍研究对象为tomcat4和tomcat5,下文中有些知识已经过时。
本章节是"深析Tomcat容器工作流程"的续文。如有不理解的地方,请先阅读上文。
该章节旨在说明当连接器调用了servlet容器的invoke()方法后会发生什么事。然后,在对应小节中讨论org.apache.catalina包中的4个相关接口,Pipleline、Valve、ValveContext和Conntained。
管道包含该servlet容器将要调用的任务。一个阀表示一个具体的执行任务。在servlet容器的管道中,除了有一个基础阀,还可以添加任意数量的阀。阀的数量指的是额外添加的阀数量,即不包括基础阀。有意思的是,可以通过编辑Tomcat的配置文件(server.xml)来动态地添加阀。下图显示了一条管道及其阀。
如果你对servlet编程中的过滤器有所了解的话,那么应该不难想像管道和阀的工作机制。管道就像过滤器链一样,而阀则好似是过滤器。阀与过滤器类似,可以处理传递给它的request对象和response对象。当一个阀执行完成后,会调用下一个阀继续执行。基础阀总是最后一个执行的。
一个servlet容器可以有一条管道。当调用了容器的invoke()方法后,容器将处理工作交由管道完成,而管道会调用其中的第一个阀开始处理。当第一个阀处理完后,它会调用后续的阀继续执行任务,直到管道中所有的阀都处理完成。下面是在管道的invoke()方法中执行的伪代码:
但是,Tomcat4的设计者选择了另一种实现方法,通过引入接口org.apache.catalina.ValveContext来实现阀的遍历执行。下面是它的工作原理。
当连接器调用容器的invoke()方法后,容器中要执行的任务并没有硬编码写在invoke()方法中,相反,容器会调用其管道的invoke()方法。Pipeline接口的invoke()方法的签名与Container接口的invoke()方法完全相同,如下所示:
其中pipeline是该容器中的Pipeline接口的实例。【在Tomcat7中我没找到Pipeline的invoke方法】
现在,管道必须保证添加到其中的所有阀及其基础阀都被调用一次,这是通过创建一个ValveContext接口实例来实现的【Tomcat7中已找不到该接口】。ValveContext是作为管道的一个内部类实现的,因此,ValveContext接口就可以访问管道的所有成员。ValveContext接口的最重要的方法是invokeNext():
在创建了ValveContext实例后,管道会调用ValveContext实例的invokeNext()方法。ValveContext实例会首先调用管道中的第一个阀,第一个阀执行完后,会调用后面的阀继续执行。ValveContext实例会将自身传给每个阀,因此,每个阀都可以调用ValveContext实例的invokeNext()方法。下面是Valve接口的invoke()方法的签名:
public void invoke(Request request, Response response) throws IOException, ServletException;
org.apache.catalina.coreStandardPipeline类是所有servlet容器的中Pipeline接口的实现。在Tomcat4中,该类有一个实现了ValveContext接口的内部类,名为StandardPipelineValveContext。代码清单5-1给出了StandardPipelineValveContext类的定义。
invokeNext()方法使用变量subscript和stage标明当前正在调用的阀。当第一次调用管道的invoke()方法时,subscript的值为0,stage的值为1,因此,第1个阀(数组索引为0)会被调用。管道中的第1个阀接收ValveContext实例,并调用其invokeNext()方法。这时,subscript的值变为1,这样就会调用第2个阀,此后以此类推。
当从最后一个阀用invokeNext()方法时,subscript的值等于阀的数量,于是,基础阀被调用。
Tomcat5才StandardPipeline类中移除了StandardPipelineValveContext类,却使用了org.apache.catalina.core.StandardValveContext类来调用阀,StandardValveContext类的定义在代码清单5-2中给出。
你能看出Tomcat 4中StandardPipelineValveContext类和Tomcat 5中的StandardValveContext类的相似点吗?
在Tomact7中,早已移除了ValveContext,那在Tomcat7中是如何实现阀的遍历执行呢?在此我先找到了tomcat4、tomcat5和tomcat7版本的Valve、Pipeline接口:
tomcat7 Valve。(Pipeline和tomcat5一样)
可以看到在tomcat5以后多提供了一个getNext方法,这个方法说明是:如果有的话,返回包含此阀门的管道中的下一个阀门。而且在tomcat5之后,Pipeline也多提供了一个方法getFirst,这个方法的说明是:返回已被区分为该管道的基本Valve的Valve实例(如果有)。
Valve中加了getNext可以看出,这个getNext返回的依旧是一个Valve,这样的话,在同一个管道内,就可以先使用getFirst获取第一个阀并invoke执行它,在invoke内又可以getNext去获取下一个阀并执行,直到getNext返回值为空时,可以调用管道的getBasic方法,获取基础阀并invoke执行它。那只要在每个容器的基础阀中调用下一个容器管道的getFirst不就能遍历执行这些阀了嘛!比如说StandardEngineValve中先拿到它的管道,然后getFirst获取第一个阀,等非基础Valve执行完了,然后执行它的basic Valve,执行basic Valve时在调用Engine的子元素StandardHost中StandardHostValve的管道,然后使用StandardHostValve管道的getFisrt继续这样下去,所有的阀就得到执行了。
现在,我们要详细介绍几个接口,包括Pipeline、Valve和ValveContext。此外,还会讨论一个阀类通常都会实现的接口org.apache.catalina.Contained。
Tomcat4中对于Pipeline接口,首先要提到的一个方法是invoke()方法,servlet容器调用invoke()方法来开始调用管道中的阀和基础阀。通过调用Pipeline接口的addValve()方法,可以向管道中添加新的阀,同样,也可以调用removeValve()方法从管道中删除某个阀。最后,调用setBasic()方法将基础阀门设置到管道中,调用其getBasic()方法则可以获取基础阀。基础阀是最后调用的阀,负责处理request对象及其对应的response对象。代码清单5-3给出了Pipeline接口的定义。
Tomcat7中对于Pipeline接口,已经不在有invoke()方法,在容器初始化的时候创建好一个StandardPipeline
由上图看出既然StandardPipeline实现了Lifecycle,则它必须管理自己的生命周期,这一点就和其他StandardContext,StandardEngine等一样,它们都要经历过NEW-...>STARTED。
分别打开StandardEngine、StandardHost、StandardContext、和StandardWrapper这四个容器类,首先,执行一个类最先被执行的是构造方法,查看它们的构造方法(仅以StandardEngine为例,其他代码不在贴出):
1 public StandardEngine() { 2 3 super(); 4 pipeline.setBasic(new StandardEngineValve()); 5 /* Set the jmvRoute using the system property jvmRoute */ 6 try { 7 setJvmRoute(System.getProperty("jvmRoute")); 8 } catch(Exception ex) { 9 log.warn(sm.getString("standardEngine.jvmRouteFail")); 10 } 11 // By default, the engine will hold the reloading thread 12 backgroundProcessorDelay = 10; 13 14 }
可以看出它其中的pipeline把基础阀设置了进去,那这个pipeline从哪来的,什么时候被创建的?点进去查看pipeline可以看到它是父类ContainerBase里的一个protected属性,所以在创建StandardEngine时调用父类构造函数,此刻把这个pipeline属性也继承下来了。StandardHost、StandardContext、和StandardWrapper也都继承自ContainerBase,所以在创建它们的实例时,也都会创建一个自己的管道,并设置基础阀。
在以StandardHost的startInternal为例(因为只有它在加入了其他阀):
1 @Override 2 protected synchronized void startInternal() throws LifecycleException { 3 4 // 设置错误报告阀 5 String errorValve = getErrorReportValveClass(); 6 if ((errorValve != null) && (!errorValve.equals(""))) { 7 try { 8 boolean found = false; 9 Valve[] valves = getPipeline().getValves(); 10 for (Valve valve : valves) { 11 if (errorValve.equals(valve.getClass().getName())) { 12 found = true; 13 break; 14 } 15 } 16 if(!found) { 17 Valve valve = 18 (Valve) Class.forName(errorValve).getConstructor().newInstance(); 19 getPipeline().addValve(valve); 20 } 21 } catch (Throwable t) { 22 ExceptionUtils.handleThrowable(t); 23 log.error(sm.getString( 24 "standardHost.invalidErrorReportValveClass", 25 errorValve), t); 26 } 27 } 28 super.startInternal(); 29 }
在super.startInternal可以看到有一行代码:
1 // 启动我们管道中的阀门(包括基本阀门)(如果有) 2 if (pipeline instanceof Lifecycle) { 3 // 不断getNext获取当前管道内的下一个阀,让它们经历NEW-...>STARTED 4 ((Lifecycle) pipeline).start(); 5 }
这行代码就是把所有的阀都状态都走一遍NEW-...>STARTED。到此管道和阀都准备好了。
在tomcat启动后,请求由Connector传递给Engine,也就是说到时候肯定会有一段代码调用了Engine的管道的getFirst把请求交给容器去处理,而这个请求要经历Engine、Host、Context、Wrapper这几个容器的管道,并执行阀里的invoke方法,接下来我们就去找是否有这段代码支持我们的猜测。
我们把断点打在第一个容器的invoke()上,即找到StandardEngineValve的invoke()方法,在第一行打上断点,启动Bootstrap,然后访问http://localhost:8080/,此刻会进入断点:
打开Debugger,从下自上依次点击Frames里每一个内容,先是run:
1 @Override 2 public void run() { 3 if (target != null) { 4 target.run(); 5 } 6 }
不用想,之前咱们就分析过,socket建立以后,对于每一个请求会创建一个独立的线程去处理,这个线程只不过是被tomcat封装了一下,在往上可以看到一个咱们之前分析过的对象ThreadPoolExecutor,这是tomcat创建的一个线程池,对于到来的socket连接请求,都会从这个池中获取一个线程去执行这个请求。在网上,JIOEndpoint,这个我也不说了就是之前的那个endpoint,我们重点看看当前它执行的方法是啥,是run方法的这一行:
执行了一个handler.process,这个handle是Http11Protocol的一个内部类Http11ConnectionHandler的实例。在往上是AbstractProtocol$AbstractConnectionHandler内部类的方法process。在往上是AbstractHttp11Processor的process【关于tomcat连接器Connector连接器这一块我不是很熟,有时间在读一下这本书】,执行到这一行:
这个adaptor,他就是CoyoteAdapter,之前我们也说过,给Http11Protocol做个适配的。在往上进入这个适配类的service方法,找到我们期盼的与肯定的代码:
在往上不用说了,肯定是进入StandardEngineValve的invoke方法,管道和阀开始起作用。
Tomcat4中阀是Valve接口的实例,用来处理接收到的请求。该接口有两个方法,invoke()方法和getInfo()方法。invoke()方法已经在前面讨论过了,getInfo()方法返回阀的实现信息。代码清单5-4给出了Valve接口的定义。
在Tomcat7中上面管道章节中,我们也跟踪源码了,为什么tomcat会有管道和阀,而不是直接把请求交给StandardEngine,我想这也不必我多说,你心里多少也有些想法,有了管道和阀可以不断的对该管道中的阀进行调用,相当于一条链上的多个Filter一样,通过管道和阀去控制、设置请求和响应。
每个标准实现类都有一个标准实现类的阀,比如StandardEngine有StandardEngineValve,StandardHost有StandardHostValve。每个阀里的invoke各有特色,再次不在多说。
Tomcat4中阀可以选择是否实现org.apache.catalina.Contained接口,该接口的实现类可以通过接口中的方法至多与一个servlet容器相关联。代码清单5-6给出了Contained接口的定义。
标签:调用,Tomcat,invoke,与阀,Valve,接口,管道,方法 来源: https://www.cnblogs.com/liudaihuablogs/p/14167353.html