通过这一系列的前三部分看到了一次客户端连接在 Tomcat 内部被转换成了请求对象 (
org.apache.catalina.connector.Request
类的实例), 并在该请求对象内部将与本次请求相关的 Host,Context,Wrapper 对象的引用. 本文主要分析该请求对象在容器内部流转的经过.
再来看一下 Tomcat 7 内部的组件结构图:
其实这张图已经给出了答案, 在 Connector 接收到一次连接并转化成请求 ( Request ) 后, 会将请求传递到 Engine 的管道 ( Pipeline ) 的阀 ( ValveA ) 中. 请求在 Engine 的管道中最终会传递到 Engine Valve 这个阀中. 接着请求会从 Engine Valve 传递到一个 Host 的管道中, 在该管道中最后传递到 Host Valve 这个阀里. 接着从 Host Valve 传递到一个 Context 的管道中, 在该管道中最后传递到 Context Valve 中. 接下来请求会传递到 Wrapper C 内的管道所包含的阀 Wrapper Valve 中, 在这里会经过一个过滤器链 ( Filter Chain ), 最终送到一个 Servlet 中.
如果你不了解上面这段文字描述中所谓的管道 ( Pipeline ) 和阀 ( Valve ) 的概念, 别急, 下面会讲到这个. 先从源码层面看下这段文字描述的经过. 上面提到的
org.apache.catalina.connector.CoyoteAdapter
类的 service 方法:
public void service(org.apache.coyote.Request req,
org.apache.coyote.Response res)
throws Exception {
Request request = (Request) req.getNote(ADAPTER_NOTES);
Response response = (Response) res.getNote(ADAPTER_NOTES);
if (request == null) {
// Create objects
request = connector.createRequest();
request.setCoyoteRequest(req);
response = connector.createResponse();
response.setCoyoteResponse(res);
// Link objects
request.setResponse(response);
response.setRequest(request);
// Set as notes
req.setNote(ADAPTER_NOTES, request);
res.setNote(ADAPTER_NOTES, response);
// Set query string encoding
req.getParameters().setQueryStringEncoding
(connector.getURIEncoding());
}
if (connector.getXpoweredBy()) {
response.addHeader("X-Powered-By", POWERED_BY);
}
boolean comet = false;
boolean async = false;
try {
// Parse and set Catalina and configuration specific
// request parameters
req.getRequestProcessor().setWorkerThreadName(Thread.currentThread().getName());
boolean postParseSuccess = postParseRequest(req, request, res, response);
if (postParseSuccess) {
//check valves if we support async
request.setAsyncSupported(connector.getService().getContainer().getPipeline().isAsyncSupported());
// Calling the container
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);
if (request.isComet()) {
if (!response.isClosed() && !response.isError()) {
if (request.getAvailable() || (request.getContentLength() > 0 && (!request.isParametersParsed()))) {
// Invoke a read event right away if there are available bytes
if (event(req, res, SocketStatus.OPEN)) {
comet = true;
res.action(ActionCode.COMET_BEGIN, null);
}
} else {
comet = true;
res.action(ActionCode.COMET_BEGIN, null);
}
} else {
// Clear the filter chain, as otherwise it will not be reset elsewhere
// since this is a Comet request
request.setFilterChain(null);
}
}
}
AsyncContextImpl asyncConImpl = (AsyncContextImpl)request.getAsyncContext();
if (asyncConImpl != null) {
async = true;
} else if (!comet) {
request.finishRequest();
response.finishResponse();
if (postParseSuccess &&
request.getMappingData().context != null) {
// Log only if processing was invoked.
// If postParseRequest() failed, it has already logged it.
// If context is null this was the start of a comet request
// that failed and has already been logged.
((Context) request.getMappingData().context).logAccess(
request, response,
System.currentTimeMillis() - req.getStartTime(),
false);
}
req.action(ActionCode.POST_REQUEST , null);
}
} catch (IOException e) {
// Ignore
} finally {
req.getRequestProcessor().setWorkerThreadName(null);
// Recycle the wrapper request and response
if (!comet && !async) {
request.recycle();
response.recycle();
} else {
// Clear converters so that the minimum amount of memory
// is used by this processor
request.clearEncoders();
response.clearEncoders();
}
}
}
之前主要分析了第 42 行的代码, 通过 postParseRequest 方法的调用请求对象内保存了关于本次请求的具体要执行的 Host,Context,Wrapper 组件的引用.
看下第 47 行:
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);
虽然只有一行, 但调用了一堆方法, 这里对这些方法逐个分析一下:
connector.getService() 获取的是当前 connector 关联的 Service 组件, 默认情况下获得的就是
org.apache.catalina.core.StandardService
的对象. 其 getContainer 方法获得的是
org.apache.catalina.core.StandardEngine
的对象, 这段的由来在 前面讲 Digester 的解析文章 时, createStartDigester 方法中的这段代码:
digester.addRuleSet(new EngineRuleSet("Server/Service/"));
在 EngineRuleSet 类的 addRuleInstances 方法中的这一段代码:
public void addRuleInstances(Digester digester) {
digester.addObjectCreate(prefix + "Engine",
"org.apache.catalina.core.StandardEngine",
"className");
digester.addSetProperties(prefix + "Engine");
digester.addRule(prefix + "Engine",
new LifecycleListenerRule
("org.apache.catalina.startup.EngineConfig",
"engineConfigClass"));
digester.addSetNext(prefix + "Engine",
"setContainer",
"org.apache.catalina.Container");
结合上一段代码可以看出 Tomcat 启动时, 如果碰到 server.xml 里的 Server/Service/Engine 节点, 先实例化一个
org.apache.catalina.core.StandardEngine
对象, 在第 11 到 13 行, 会以 StandardEngine 对象为入参调用
org.apache.catalina.core.StandardService
的 setContainer 方法.
所以上面 connector.getService().getContainer() 方法得到的实际上是 StandardEngine 对象. 紧接着的 getPipeline 方法返回的是 StandardEngine 类的父类
org.apache.catalina.core.ContainerBase
类的成员变量 pipeline , 看下该类中这个变量的声明代码:
/**
* The Pipeline object with which this Container is associated.
*/
protected Pipeline pipeline = new StandardPipeline(this);
所以 connector.getService().getContainer().getPipeline() 方法返回的是
org.apache.catalina.core.StandardPipeline
类的对象, 该对象就是本部分开头部分提到的管道 ( Pipeline ).
下面讲一下 Tomcat 7 中的管道和阀的概念和实现:
所有的管道类都会实现
org.apache.catalina.Pipeline
这个接口, 看下这个接口中定义的方法:
Tomat 7 中一个管道包含多个阀 ( Valve ), 这些阀共分为两类, 一类叫基础阀 (通过 getBasic,setBasic 方法调用), 一类是普通阀 (通过 addValve,removeValve 调用). 管道都是包含在一个容器当中, 所以 API 里还有 getContainer 和 setContainer 方法. 一个管道一般有一个基础阀 (通过 setBasic 添加), 可以有 0 到多个普通阀 (通过 addValve 添加).
所有的阀类都会实现
org.apache.catalina.Valve
这个接口, 看下这个接口中定义的方法:
重点关注 setNext,getNext,invoke 这三个方法, 通过 setNext 设置该阀的下一阀, 通过 getNext 返回该阀的下一个阀的引用, invoke 方法则执行该阀内部自定义的请求处理代码.
Tomcat 7 里 Pipeline 的默认实现类是
org.apache.catalina.core.StandardPipeline
, 其内部有三个成员变量: basic,first,container .
/**
* The basic Valve (if any) associated with this Pipeline.
*/
protected Valve basic = null;
/**
* The Container with which this Pipeline is associated.
*/
protected Container container = null;
/**
* The first valve associated with this Pipeline.
*/
protected Valve first = null;
看下该类的 addValve 方法:
public void addValve(Valve valve) {
// Validate that we can add this Valve
if (valve instanceof Contained)
((Contained) valve).setContainer(this.container);
// Start the new component if necessary
if (getState().isAvailable()) {
if (valve instanceof Lifecycle) {
try {
((Lifecycle) valve).start();
} catch (LifecycleException e) {
log.error("StandardPipeline.addValve: start:", e);
}
}
}
// Add this Valve to the set associated with this Pipeline
if (first == null) {
first = valve;
valve.setNext(basic);
} else {
Valve current = first;
while (current != null) {
if (current.getNext() == basic) {
current.setNext(valve);
valve.setNext(basic);
break;
}
current = current.getNext();
}
}
container.fireContainerEvent(Container.ADD_VALVE_EVENT, valve);
}
在第 18 到 32 行, 每次给管道添加一个普通阀的时候如果管道内原来没有普通阀则将新添加的阀作为该管道的成员变量 first 的引用, 如果管道内已有普通阀, 则把新加的阀加到所有普通阀链条末端, 并且将该阀的下一个阀的引用设置为管道的基础阀. 这样管道内的阀结构如下图所示:
即 Pipeline 内部维护 first 和 basic 两个阀, 其它相关阀通过 getNext 来获取.
看下 getFirst 方法的实现:
public Valve getFirst() {
if (first != null) {
return first;
}
return basic;
}
如果管道中有普通阀则返回普通阀链条最开始的那个, 否则就返回基础阀.
在 Tomcat 7 中所有作为普通阀的类的 invoke 方法实现中都会有这段代码:
getNext().invoke(request, response);
通过这种机制来保证调用管道最开头一端的阀的 invoke 方法, 最终会执行完该管道相关的所有阀的 invoke 方法, 并且最后执行的必定是该管道基础阀的 invoke 方法.
再回到
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response)
这段代码的解释, 这里将会执行 StandardEngine 类的管道中的所有阀 (包括普通阀和基础阀) 的 invoke 方法, 并且最后会执行基础阀的 invoke 方法.
Tomcat 7 在默认情况下 Engine 节点没有普通阀, 如果想要添加普通阀的话, 可以通过在 server.xml 文件的 engine 节点下添加 Valve 节点, 参加该文件中的普通阀配置的示例:
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
那么就来看看 StandardEngine 类的管道中的基础阀的代码实现. 先看下该基础阀设置的代码, 在
org.apache.catalina.core.StandardEngine
对象的构造函数中:
public StandardEngine() {
super();
pipeline.setBasic(new StandardEngineValve());
/* Set the jmvRoute using the system property jvmRoute */
try {
setJvmRoute(System.getProperty("jvmRoute"));
} catch(Exception ex) {
log.warn(sm.getString("standardEngine.jvmRouteFail"));
}
// By default, the engine will hold the reloading thread
backgroundProcessorDelay = 10;
}
第 4 行即设置基础阀. 所以
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response)
会执行到 org.apache.catalina.core.StandardEngineValve 类的 invoke 方法:
public final void invoke(Request request, Response response)
throws IOException, ServletException {
// Select the Host to be used for this Request
Host host = request.getHost();
if (host == null) {
response.sendError
(HttpServletResponse.SC_BAD_REQUEST,
sm.getString("standardEngine.noHost",
request.getServerName()));
return;
}
if (request.isAsyncSupported()) {
request.setAsyncSupported(host.getPipeline().isAsyncSupported());
}
// Ask this Host to process this request
host.getPipeline().getFirst().invoke(request, response);
}
第 5 行, 从请求对象中取出该请求关联的 Host(默认情况下是
org.apache.catalina.core.StandardHost
对象), 请求是如何找到关联的 Host 的请本文之前的部分. 经过上述代码分析应该可以看出第 18 行会执行 StandardHost 对象的管道内所有的阀的 invoke 方法.
看下 StandardHost 的构造方法的实现:
public StandardHost() {
super();
pipeline.setBasic(new StandardHostValve());
}
所以看下
org.apache.catalina.core.StandardHostValve
类的 invoke 方法:
public final void invoke(Request request, Response response)
throws IOException, ServletException {
// Select the Context to be used for this Request
Context context = request.getContext();
if (context == null) {
response.sendError
(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
sm.getString("standardHost.noContext"));
return;
}
// Bind the context CL to the current thread
if( context.getLoader() != null ) {
// Not started - it should check for availability first
// This should eventually move to Engine, it's generic.
if (Globals.IS_SECURITY_ENABLED) {
PrivilegedAction pa = new PrivilegedSetTccl(
context.getLoader().getClassLoader());
AccessController.doPrivileged(pa);
} else {
Thread.currentThread().setContextClassLoader
(context.getLoader().getClassLoader());
}
}
if (request.isAsyncSupported()) {
request.setAsyncSupported(context.getPipeline().isAsyncSupported());
}
// Don't fire listeners during async processing
// If a request init listener throws an exception, the request is
// aborted
boolean asyncAtStart = request.isAsync();
// An async error page may dispatch to another resource. This flag helps
// ensure an infinite error handling loop is not entered
boolean errorAtStart = response.isError();
if (asyncAtStart || context.fireRequestInitEvent(request)) {
// Ask this Context to process this request
try {
context.getPipeline().getFirst().invoke(request, response);
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
if (errorAtStart) {
container.getLogger().error("Exception Processing" +
request.getRequestURI(), t);
} else {
request.setAttribute(RequestDispatcher.ERROR_EXCEPTION, t);
throwable(request, response, t);
}
}
// If the request was async at the start and an error occurred then
// the async error handling will kick-in and that will fire the
// request destroyed event *after* the error handling has taken
// place
if (!(request.isAsync() || (asyncAtStart &&
request.getAttribute(
RequestDispatcher.ERROR_EXCEPTION) != null))) {
// Protect against NPEs if context was destroyed during a
// long running request.
if (context.getState().isAvailable()) {
if (!errorAtStart) {
// Error page processing
response.setSuspended(false);
Throwable t = (Throwable) request.getAttribute(
RequestDispatcher.ERROR_EXCEPTION);
if (t != null) {
throwable(request, response, t);
} else {
status(request, response);
}
}
context.fireRequestDestroyEvent(request);
}
}
}
// Access a session (if present) to update last accessed time, based on a
// strict interpretation of the specification
if (ACCESS_SESSION) {
request.getSession(false);
}
// Restore the context classloader
if (Globals.IS_SECURITY_ENABLED) {
PrivilegedAction pa = new PrivilegedSetTccl(
StandardHostValve.class.getClassLoader());
AccessController.doPrivileged(pa);
} else {
Thread.currentThread().setContextClassLoader
(StandardHostValve.class.getClassLoader());
}
}
第 41 行, 会调用该请求相关的 Context 的管道内所有的阀的 invoke 方法, 默认情况下 Context 是
org.apache.catalina.core.StandardContext
类的对象, 其构造方法中设置了管道的基础阀:
public StandardContext() {
super();
pipeline.setBasic(new StandardContextValve());
broadcaster = new NotificationBroadcasterSupport();
// Set defaults
if (!Globals.STRICT_SERVLET_COMPLIANCE) {
// Strict servlet compliance requires all extension mapped servlets
// to be checked against welcome files
resourceOnlyServlets.add("jsp");
}
}
看下其基础阀的 invoke 方法代码:
public final void invoke(Request request, Response response)
throws IOException, ServletException {
// Disallow any direct access to resources under WEB-INF or META-INF
MessageBytes requestPathMB = request.getRequestPathMB();
if ((requestPathMB.startsWithIgnoreCase("/META-INF/", 0))
|| (requestPathMB.equalsIgnoreCase("/META-INF"))
|| (requestPathMB.startsWithIgnoreCase("/WEB-INF/", 0))
|| (requestPathMB.equalsIgnoreCase("/WEB-INF"))) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
}
// Select the Wrapper to be used for this Request
Wrapper wrapper = request.getWrapper();
if (wrapper == null || wrapper.isUnavailable()) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
}
// Acknowledge the request
try {
response.sendAcknowledgement();
} catch (IOException ioe) {
container.getLogger().error(sm.getString(
"standardContextValve.acknowledgeException"), ioe);
request.setAttribute(RequestDispatcher.ERROR_EXCEPTION, ioe);
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
return;
}
if (request.isAsyncSupported()) {
request.setAsyncSupported(wrapper.getPipeline().isAsyncSupported());
}
wrapper.getPipeline().getFirst().invoke(request, response);
}
最后的第 35 行, 从请求中取出关联的 wrapper 对象后调用其管道内所有阀的 invoke 方法. wrapper 对象默认是
org.apache.catalina.core.StandardWrapper
类的实例, 同样是在该类的构造方法中设置的基础阀:
public StandardWrapper() {
super();
swValve=new StandardWrapperValve();
pipeline.setBasic(swValve);
broadcaster = new NotificationBroadcasterSupport();
}
有兴趣可以看下基础阀
org.apache.catalina.core.StandardWrapperValve
的 invoke 方法, 在这里最终会调用请求的 url 所匹配的 Servlet 相关过滤器 ( filter ) 的 doFilter 方法及该 Servlet 的 service 方法 (这段实现都是在过滤器链 ApplicationFilterChain 类的 doFilter 方法中), 这里不再贴出代码分析.
这里可以看出容器内的 Engine,Host,Context,Wrapper 容器组件的实现的共通点:
这些组件内部都有一个成员变量 pipeline , 因为它们都是从
org.apache.catalina.core.ContainerBase
类继承来的, pipeline 就定义在这个类中. 所以每一个容器内部都关联了一个管道.
都是在类的构造方法中设置管道内的基础阀.
所有的基础阀的实现最后都会调用其下一级容器 (直接从请求中获取下一级容器对象的引用, 在上面的分析中已经设置了与该请求相关的各级具体组件的引用) 的 getPipeline().getFirst().invoke() 方法, 直到 Wrapper 组件. 因为 Wrapper 是对一个 Servlet 的包装, 所以它的基础阀内部调用的过滤器链的 doFilter 方法和 Servlet 的 service 方法.
正是通过这种管道和阀的机制及上述的 3 点前提, 使得请求可以从连接器内一步一步流转到具体 Servlet 的 service 方法中. 这样, 关于 Tomcat 7 中一次请求的分析介绍完毕, 从中可以看出在浏览器发出一次 Socket 连接请求之后 Tomcat 容器内运转处理的大致流程.
来源: https://juejin.im/post/5a72c2886fb9a01ca915c732