Tomcat Architecture Analysis (Overview)

Source: http://gearever.iteye.com 

Tomcat is the most widely used servlet container. Regarding the characteristics and introduction of tomcat itself, there are already many descriptions on the Internet, so I won't repeat them here. In addition to supporting common web apps, Tomcat's highly modular architecture also brings maximum scalability. At present, the tomcat version has been derived to tomcat7, but the mainstream version is still tomcat6. This series of architecture system introduction is still based on tomcat6. 
Tomcat is organized by a series of logical modules, these modules mainly include: 

• Core architecture modules, such as Server, Service, engine, host, context and wrapper, etc.
• network interface module connector
• log module
• session management module
• jasper module
• naming module
• JMX module
• Access control module
• ……

These modules will be described one by one in the relevant documents. This document mainly introduces the core architecture modules. 

The core architecture module indicates that 
there is a layer-by-layer inclusion relationship between the core architecture modules. For example, it can be said that Service is a child component of Server, and Server is the parent component of Service. The relationship and configuration between these components has been clearly defined in server.xml. 
It should be emphasized that the Engine for the actual work is configured in the Service, and the thread group Executor for processing time services is configured (if not configured, the thread group in the default WorkThread mode of the system is used), and the related component connector for processing network sockets. Details are shown in the figure. 
 
In the figure, 1:n represents a one-to-many relationship; 1:1 represents a one-to-one relationship. 

StandEngine, StandHost, StandContext and StandWrapper are containers, and there is a mutual containment relationship between them. For example, StandEngine is the parent container of StandHost, and StandHost is the child container of StandEngine. There is also an Executor and Connector in the StandService. 
1) Executor is a thread pool. Its specific implementation is the executor implemented by the concurrent package of java. This is not necessary. If it is not configured, the self-written worker thread thread pool is used. 
2) Connector is a network socket related interface module, which contains Two objects, ProtocolHandler and Adapter 

• ProtocolHandler receives socket requests and parses them into HTTP request objects, which can be configured in nio mode or traditional io mode
• Adapter is the object that handles HTTP requests, it is called from the valve of StandEngine to the valve of StandWrapper

Hierarchical modeling 
may be abstract for the above-mentioned logic modules. In fact, a server is nothing more than accepting an HTTP request, then processing the request, and generating an HTTP response back to the client (browser) through the original connection. Then why are so many modules out for processing? Are these modules a bit redundant? 
In fact, these modules perform their respective functions. We start from the bottom wrapper and go back to the top server. This is easy to understand. Through these descriptions, you will find that this is the embodiment of the highly modularized tomcat architecture. These subdivided modules make tomcat very robust, and through some configuration and module customization, tomcat can be extended to a great extent. 
First, we take a typical page visit as an example, assuming that the visited URL is 

quote

http://www.mydomain.com/app/index.html

Details are shown in the figure. 
 

• Wrapper encapsulates specific access resources, such as index.html
• Context encapsulates a collection of wrapper resources, such as app
• Host encapsulates a collection of various context resources, such as www.mydomain.com

According to the domain model, this typical URL access can resolve three layers of domain objects, and they have affiliation with each other. This is the most basic modeling. From the above analysis, it can be seen that from wrapper to host, it is progressive and combined layer by layer. So what is the set of host resources, which is the engine mentioned above. If the above three containers can be regarded as the encapsulation of the physical model, then the engine can be regarded as a logical encapsulation. 

Well, with the support of this whole set of engines, we can complete the positioning from engine to host to context and then to a specific wrapper, and then process business logic (about how to deal with business logic, it will be in a later blog. described in). For example, a hotel has completed the construction and decoration of various guest rooms and other hardware facilities, and the next step is the reception work at the front desk. 

Let's talk about the thread pool first, which is a typical thread pool application. First, an available thread (if any) is taken from the thread pool to process the request. This component is the connector. It is like a hotel receptionist registering guest information for check-in. It mainly completes the analysis of HTTP messages. According to the internal mapping rules of tomcat, it completes the positioning from engine to host to context and then to a specific wrapper, performs business processing, and then Will return the result back. After that, the processing ends, and the thread returns to the thread pool to serve the next request. 

If there are no idle threads available in the thread pool, the request is blocked and waits for an idle thread to process until the blocking timeout. There are two types of thread pool implementations: executor and worker thread. The default is worker thread mode. 

At this point, it can be said that a hotel has a reception desk and hardware facilities such as rooms, and it can start its formal operation. Then encapsulate the engine, processing thread pool, and connector together to form a complete and independent processing unit, which is service, just like an independent hotel. 

Usually, we often see hotels under XX group. That is, each brand has multiple hotels operating simultaneously. It's like there are multiple services running alone in tomcat. Then the collection of these multiple services is the server, just like the group to which the hotel belongs. 

Scope 
Then why encapsulate an object hierarchically? This is mainly to facilitate unified management. Similar to the concept of namespace, the scope of configuration at different levels is different. Take the RequestDumperValve that comes with tomcat for printing request and response messages as an example. The classpath for this valve is: 

quote

org.apache.catalina.valves.RequestDumperValve

 

The valve mechanism is a very important processing logic mechanism for tomcat, which will be specifically described in the relevant documents. If this valve is configured under the server.xml node, it will only print out the request and response messages for accessing this app (my). 

Xml code

<Host name="localhost" appBase="webapps"  
          unpackWARs="true" autoDeploy="true"  
          xmlValidation="false" xmlNamespaceAware="false">  
             <Context path="/my" docBase=" /usr/local/tomcat/backup/my" >  
                   <Valve className="org.apache.catalina.valves.RequestDumperValve"/>  
             </Context>  
             <Context path="/my2" docBase=" /usr/local/tomcat/backup/my" >  
             </Context>  
  </Host>

 

If this valve is configured under the server.xml node, it can print out the request and response messages that access the two apps under this host. 

Xml code

<Host name="localhost" appBase="webapps"  
                unpackWARs="true" autoDeploy="true"  
                xmlValidation="false" xmlNamespaceAware="false">  
                    <Valve className="org.apache.catalina.valves.RequestDumperValve"/>  
                    <Context path="/my" docBase=" /usr/local/tomcat/backup/my" >  
                    </Context>  
                    <Context path="/my2" docBase=" /usr/local/tomcat/backup/my" >   
                    </Context>  
  </Host>

 

A default server.xml configuration is posted here. Through these configurations, you can deepen your understanding of the layered modules of the core architecture of tomcat. The configuration of tomcat will be explained separately in the relevant documents. For the sake of space, I have deleted the comments in it. 

Xml code

<Server port="8005" shutdown="SHUTDOWN">  
         <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />  
         <Listener className="org.apache.catalina.core.JasperListener" />   
         <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />  
         <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />  
         <GlobalNamingResources>  
              <Resource name="UserDatabase" auth="Container"  
                      type="org.apache.catalina.UserDatabase"  
                     description="User database that can be updated and saved"  
                     factory="org.apache.catalina.users.MemoryUserDatabaseFactory"  
                     pathname="conf/tomcat-users.xml" />   
          </GlobalNamingResources>  
          <Service name="Catalina">  
               <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"   
                     maxThreads="150" minSpareThreads="4"/>  
               <Connector port="80" protocol="HTTP/1.1"   
                     connectionTimeout="20000"   
                     redirectPort="7443" />  
               <Connector port="7009" protocol="AJP/1.3" redirectPort="7443" />  
               <Engine name="Catalina" defaultHost="localhost">  
                    <Realm className="org.apache.catalina.realm.UserDatabaseRealm"  
                           resourceName="UserDatabase"/>  
                    <Host name="localhost" appBase="webapps"  
                           unpackWARs="true" autoDeploy="true"  
                           xmlValidation="false" xmlNamespaceAware="false">  
                           <Context path="/my" docBase="/usr/local/tomcat/backup/my" >  
                           </Context>   
                    </Host>   
                </Engine>  
            </Service>  
  </Server>

 

At this point, you should have the concept of the overall architecture of tomcat in your mind. I have time to write something about other modules.