Tomcat source Resolution-the overall process introduction

First, the framework

Let's talk about my understanding of Tomcat architecture.

Overall architecture:

1. Component-Oriented Architecture

2, based on JMX

3. Event Listening

1) component-oriented architecture

The tomcat code looks large, but structurally clear and simple, consisting primarily of a bunch of components, such as servers, Service, connector, and so on, and managing these components based on JMX, In addition, the component that implements the interface above also implements the interface lifecycle representing the lifetime, so that its components perform a fixed lifetime and extend through the event listening lifecycleevent during its whole lifetime. The core class diagram for Tomcat looks like this:

1. Catalina: The main class that interacts with the start/close shell script, so if you want to study the startup and shutdown process, start looking at this class.

2, Server: Is the entire Tomcat component container, contains one or more service.

3, Service:service is a collection of connector and container, Service with the appropriate connector to receive the user's request, and then sent to the corresponding container to deal with.

4, Connector: The realization of a certain protocol connectors, such as the default has the implementation of HTTP, HTTPS, AJP protocol.

5, Container: Can be understood as the processing of a type of request container, the way to deal with the processing of the request is generally packaged as a valve object, and in a certain order into the type of pipeline pipeline. Container have multiple seed types: Engine, Host, context, and wrapper, and these seed types are container in sequence, processing different granularity requests. In addition, container includes some basic services, such as loader, manager, and Realm.

6, Engine:engine contains host and context, received the request still to the corresponding host in the corresponding context to deal with.

7, Host: Is that we understand the virtual host.

8, Context: Is our subordinates of the specific Web application contexts, each request is in the context of the corresponding processing

9, Wrapper:wrapper is for each servlet container, each servlet has the corresponding wrapper to manage.

You can see that the core components of the server, Service, Connector, Container, Engine, Host, context, and wrapper are progressively descending by layer and are included on a per-layer basis.

Here are some of the basic components that are used by container:

1, Loader: Is container used to load a variety of required class.

2, Manager: Is container used to manage the session pool.

3, Realm: is used to deal with security authorization and certification.

After analyzing the core classes, and then looking at the Tomcat boot process, the sequence diagram of the Tomcat boot is as follows:

As you can see from the figure above, Tomcat startup is divided into init and start two processes, the core components implement the Lifecycle interface, all need to implement the Start method, so in the START process is to start from the server layer called the child component start process.

2) based on JMX

Tomcat registers the process for each component, managed through registry, and Registry is based on JMX, so looking at the component's init and start processes is actually initializing the Mbean and triggering the Mbean's Start method, Will see a lot of shapes like:

Registry.getregistry (null, NULL). Invoke (Mbeans, "Init", false); Registry.getregistry (null, NULL). Invoke (Mbeans, "start", false);

Such code, which is actually the behavior and lifetime of managing various components through JMX.

Not familiar with jmx visible:

3) Event Listening

Each component has a variety of behaviors in its lifetime, and these actions trigger the corresponding event, and Tomcat is listening to these times to extend the behavior. See a lot of the init and start processes for components like this:

Lifecycle.firelifecycleevent (after_start_event, NULL);

Such code, which is the trigger for a type of event, if you want to add your own behavior to it, just register the appropriate type of event.

二、一次 full request in and out

A few days ago, I analyzed Tomcat's architecture and startup process, and began to study its operating mechanism today. Tomcat is essentially a Web server that can run Jsp/servlet, so the most typical application is that the user accesses the server through the browser, the Tomcat receives the request, and sends it to the servlet, which is processed by the servlet and returns the result to the client. Today, the internal mechanism of such a complete request is specifically parsed.

With Debug, along the way, the core process of Tomcat processing requests is found to be the following:

1, when starting the pre-support protocol Endpoint,endpoint will be a dedicated thread to listen for the corresponding protocol request, by default, will start Jioendpoint,jioendpoint based on Java ServerSocket receive HTTP request

2, ServerSocket received the client request socket, all the way packaging, and from the host has been passed to wrapper, and then requested to the corresponding servlet

The above two processes are highlighted below.

Through the previous analysis (Tomcat source analysis one) can know that when Tomcat starts the connector will start, at this time connector will be through the Protocolhandler to endpoint start up. By default, Tomcat initiates two connector, the HTTP protocol and the AJP protocol, followed by Http11protocol and Ajpprotocol, both of which start jioendpoint. Here's a look at the Jioendpoint Start method:

public void Start () throws Exception { //Initialize socket if not done before if (!initialized) { init (); } if (!running) { running = true; paused = false; Create Worker Collection if (getexecutor () = null) { createexecutor (); } Start Acceptor threads for (int i = 0; i < Acceptorthreadcount; i++) { thread acceptorthread = new Thread ( New Acceptor (), getName () + "-acceptor-" + i); Acceptorthread.setpriority (threadpriority); Acceptorthread.setdaemon (Getdaemon ()); Acceptorthread.start ();}}

The above code is very clear to start acceptorthreadcount threads, each thread by the acceptor agent, specifically look at the acceptor Run method:

public void Run () {//loop until we receive a shutdown command while (running) {//loop if en Dpoint is paused while (paused) {try {thread.sleep (1000); catch (Interruptedexception e) {//Ignore}}//Accept the next in Coming connection from the server socket try {socket socket = Serversocketfactory.acceptsocket (SE Rversocket); Serversocketfactory.initsocket (socket); Hand this socket is appropriate processor Process the socket if (!processsocket (socket)) { //close socket right away try { socket.close (); } catch ( IOException e) { //Ignore } } }catch (IOException x) { if (running) log.error (sm.getstring ("ENDP Oint.accept.fail "), x); catch (Throwable t) { log.error (sm.getstring ("Endpoint.accept.fail"), t); The processor'll recycle itself when it finishes } }

This leads to the conclusion that Tomcat receives requests from clients by ServerSocket the way it listens for sockets. The specific code does not need me to parse, a little understanding of Java net people can understand the above code, Tomcat is the most standard and most basic socket call method to handle network requests. When you find the source of the request, the next thing to do is simply, break the breakpoint, and ask for the simplest Hello world in the browser and debug it all the way down. Along the way, the sequence diagram of the main flow is as follows:

from the above diagram, the above process can be decomposed into the following three main core points:

1, based on the Http1.1 protocol to the socket Analysis and packaging

2, Standardenginevalve, Standardhostvalve, standardcontextvalve and standardwrappervalve valve of four inoke. Four different levels of valve do different levels of processing and encapsulation

3, based on the responsibility chain mode Applicationfilterchain implement filter interception and the actual servlet request

The above three core points are very rich in content can be studied, will be in the next few days to analyze one by one.

Three, can carry the state of the thread pool

A recent desire to implement a portable thread pool is that the thread in the pool is used to process some kind of information, which can be considered an external state that the thread relies on. If implemented with a simple thread pool, threads should be initialized with some information so that the thread cannot be used again. Look at the old version of Tomcat source, found the answer, its implementation of the main idea is to use the thread of the wait and arouse, httpprocessor implementation is based on this idea, the sequence diagram as follows:

When initializing a httpprocessor thread, it is impossible to give the desired socket object, because if the socket is given during initialization, the thread cannot be recycled to handle other sockets. Therefore, in the Httpprocessor run phase, first the thread to wait, specifically in the await method embodiment, the code is as follows:

/** * Await A newly assigned Socket from my Connector, or null * If we are supposed to shut down. * Private synchronized socket await () { //wait for the Connector to provide a new socket while (!available) { try {wait (); } catch (Interruptedexception e) { } } //Notify The Connector that we have rec Eived this socket socket = This.socket; Available = false; Notifyall (); if (debug >= 1) && (socket!= null) log ("The incoming request has been awaited"); return (socket);

When HttpConnector calls the Httpprocessor.assign (socket) method, the thread is given the socket object and the thread is invoked to continue execution, and the source code for the Assign method is as follows:

/** * Process an incoming TCP/IP connection on the specified socket. Any * exception that occurs during processing must is logged and swallowed. Note: This is the called from our Connector ' s thread. We * Must assign it to my own thread so, multiple simultaneous * requests can be handled. * * @param socket TCP socket to process /synchronized void assign (socket sockets) { //wait for the P Rocessor to get the previous Socket while (available) { try {wait (); } catch (Interruptedexception E { } } //Store the newly available socket and notify our thread this.socket = socket; Available = true; Notifyall (); if (debug >= 1) && (socket!= null) log ("A incoming request is being assigned");

After the thread is aroused and given the socket object, continue to execute the core process method, Httpprocessor.run the complete source code as follows:

/** * The background thread that listens for incoming TCP/IP connections and * hands them off to a appropriate PR Ocessor. */Public void Run () { //Process requests until we receive a shutdown signal while (!stopped) {/ /wait F Or the next socket to is assigned socket socket = await (); if (socket = = NULL) continue; Process the request from this socket try { process (socket); } catch (Throwable t) { log ("Process.i Nvoke ", t); } Finish up the request connector.recycle (this); } Tell Threadstop () We have shut ourselves down successfully synchronized (threadsync) { Threadsync.notifyall (); } }

The whole process of request and response processing

From the Tomcat Source Analysis (ii), a user request will be processed through the N-Link, and finally to the developer to write the servlet, passed to the servlet is HttpServletRequest and HttpServletResponse, So you can think that all the way down is simply the most original socket packaging into a servlet used in the HttpServletRequest and httpservletresponse, but each link to complete the packaging function and part of the different just, The information flow is shown in the following illustration:

The class diagram for request and response is shown below:

Org.apache.coyote.Request and Org.apache.coyote.Response are used internally by Tomcat and are not available to the developer to call, the class is final type. The following is a complete request sequence diagram to see the processing process from socket to org.apache.catalina.connector.Request:

From the above figure can be seen, request parsing and processing process is not in a method to fix, but the flow of information is gradually resolved, different levels of the processor to resolve different levels of information, in the parsing process at the same time to do some judgment and interception of work, such as when found to access web-inf resources, will return the error directly to the client and so on.

Note: For reference only, record here