Server: Apache Tomcat-Understanding the architecture hierarchy

Article overview

Believe that many people who touch Java are familiar with how much Tom Cat, personally, originally only know Tom simple operation and configuration, like wrapped in a layer of yarn, stumbled.

Tomcat books are not much, high scores or a long time ago version, until recently read the following book, answered a lot of my questions, and this article will summarize the reading harvest.

If you feel that the article is interesting to you or that my cat is interested in you, it is recommended that you read this book.

　　

This article introduces Tom's architecture, how servers are abstracted from one layer to the complete architecture

About Tomcat

Tom is a world-renowned lightweight application server, based on Java, serving Java. It is primarily used as an application server to handle dynamic resource responses from clients.

The current version is 9.x, many people are using 6.x, but the new version actually provides a lot of features, such as WebSocket support, click to learn WebSocket.

　　　　

Tomcat Boot parameters

Windows modifies $catalina_home/bin/catalina.bat files

Set java_opts=-server-xms1024m-xmx2048m-xx:permsize=256m-xx:maxpermsize=512m

Linux Modify $catalina_home/bin/catalina.sh File

Java_opts= "-server-xms1024m-xmx2048m-xx:permsize=256m-xx:maxpermsize=512m"

-server server-side startup Tomcat,client boot tomcat The initialization parameters for both are different

-xms1024m Initializing heap memory size

Maximum heap memory size allowed by-xmx2048m

-xx:permsize=256m initialization of non-heap memory size

-xx:maxpermsize=512m maximum amount of non-heap memory allowed

　　Debug mode

Dependent on JDK-provided JPDA (Java Platform Debugger Architecture,java Platform Debug architecture)

Catalina JPDA Start

　　Directory structure

　　　　

The version used in this article is apache-tomcat-9.0.1, and the catalogue is generally easy to understand.

Conf placed the core configuration file for Tomcat, which is described later.

WebApps is the default app directory for Web apps and can be run as long as the project directory is put in.

Work is where the JSP compilation files generated by the Tomcat runtime are stored

Overall architecture

Tomcat is an application server, and we evolve from the most fundamental class layer to the current version of Tomcat.

1. The application server receives and resolves the request data from other computers (clients), completes the related business process, and returns the processing result as a response to the computer.

　　

2. a problem is in front of you, before the server request listening and request processing put together, the application server usually with the Web server cluster deployment and load balancing, but the protocol is not HTTP.

In other words, the other end of the server connection needs to be adapted to different protocols to handle the request differently. The preceding model has poor extensibility and should separate request listening and request processing.

Connector module Management request monitoring, the container module is responsible for request processing, two components have start () and stop () to load and release their own maintenance of resources .

In this way, there can be multiple connector under the server to transmit the request to a different container.

3. The above design has a flaw, since the server can have multiple connector and container, then how to know which connector will send the request to which container?

Consider the following design diagram,

4. The tomcat we've been exposed to should be the container where the web app is placed, and where to place the Web App? This will determine which app handles the request information obtained by the engine.

Think again, our browser is an app, right? Then the server is actually an app, right? The network is the communication between the two. Let's look at how the network communicates.

Yes, the Web app needs endpoint information (IP address, port number), and we need to provide this layer of abstraction. A host can have multiple apps (context) under it.

5. Now that the design has been able to meet the connection of two applications, now imagine how the application should be represented? After all, Tomcat exists as a servlet container. First Apache organization, in accordance with the official servlet standards, Added the Servlet wrapper class wrapper.

6. So far, we have used the concept of " container " to describe the component that processes the request of the receiving client and return the response data , and in this case, using a class container to unify the idea, let the engine, Host,context,wrapper such components to inherit the container.

The container class is able to add subcomponents addchild methods, sometimes requiring some asynchronous processing, so join the Backgroundprocess method.

Since the reference to Engine,host,context,wrapper is turned into a parent class container, the previous strong composition relationship becomes a weakly associative relationship. The strength-to-power relationship refers to two classes that are either directly or indirectly related.

7. in order to review the current design from the abstraction and reuse level, make the concept clearer and provide a universal definition. since all containers have their own life cycle management methods, we can abstract them into an interface lifecycle, adding initialization method init to the method definition, destroying method destroy, Event Listener Methods Addlifecyclelistener and Removelifecyclelistener.

8. the container part of the above design is scalable and scalable, which is great. Next, Tomcat's developers are making it easier to extend the flexibility of each component, Added both pipeline and valve interfaces. The design of these two interfaces uses the responsibility chain model.

Brief introduction of the following responsibility chain model, about design patterns can be viewed in the blog article "Software Design: Focus on design mode"

The responsibility chain pattern uses an abstract class to define the processor uniformly, then constructs the processor into a chain, and when the client sends a request, the first handler determines whether or not to handle it, and then passes it down a handler until the processing or the processing chain ends.

Looking back at how Tomcat uses this design pattern, thepipeline interface is used to build the responsibility chain, and the valve interface represents each processor on the responsibility chain.

The pipeline maintains a base valve, which is always located at the end of the pipeline execution chain, encapsulating the specific request handling and output response processes.

So you can construct a chain of responsibilities, but why do you do it? Remember before container is a container that can be self-contained? Why do I have to make two more interfaces?

Indeed, container can be self-contained, but it exists as a container abstract class, and Valve is present as an interface, and we can add our own valve implementation class to the class that implements this interface, whatever you want to do.

　　Like a water pipe, if you are Super Mario, you can always add a valve to it and do anything.

9. The front design basically falls in the container section, looks at the connector design scheme, connector must complete the following function item.

① Listening server ports, reading requests from clients

② to parse the request data according to the specified protocol

③ processing According to the correct container for the request address

④ returning the request to the client

Tomcat supports multi-Protocol (HTTP/AJP) and multiple IO modes (BIO,NIO,NIO2,APR,HTTP/2)

　　

Protocolhandler represents a protocol processor that provides different implementations for different protocols and IO modes, and Protocolhandler contains a endpoint to initiate socket snooping, which is categorized by IO. It also contains a process for reading data according to the specified protocol and handing it over to the container.

The processing logic is as follows:

1. At connector startup, endpoint initiates a thread to listen to the server port and calls process to read the data after the request is received.

2. When the process reads a client request, it needs to be mapped to a specific container for processing, that is, request mapping.

3. Because the Tomcat components are managed in a common life cycle and state changes are made through management tools, the request mapping takes into account the registration and destruction of the container components in addition to the implementation of the mapping rules.

Tomcat uses Mapper to maintain container mapping information and finds containers according to mapping rules (servlet specification definitions);

Mapperlistener implements Lifecyclelistener and ContainerListener to register or cancel the corresponding container mapping information when the container component state changes;

Mapperlistener implements the lifecycle interface, which is automatically registered as a listener on each container component when the service is started, and registers the created container with the mapper;

Tomcat realizes the decoupling of connector and Mapper,container by adapter mode, and the default implementation is Coyotoadapter;

Here, the server can access the request and complete the response, but we have not considered a key issue--concurrent

Tomcat uses a component-style design concept, and then there are concurrent components.

The Tomcat organization provides a executor interface for this to represent a pool of threads that can be shared among components , which also inherits from the lifecycle interface and is managed by common components.

The executor is maintained by the service, so the components in the same service share a thread pool. It is important to note that if a thread pool is not defined, the associated component automatically creates the thread pool, which is no longer shared.

In Tomcat, endpoint initiates a set of threads to listen for the socket port, and when a customer request is received, the request processing object is created and processed by the thread pool, which supports concurrent processing of client requests.

One . now the core components of the Tomcat base are complete, but there are still many components that are not shown in the architecture. Tomcat developers provide a set of configuration environments to support the system's configurable--catalinain order for users to use Tomcat well.

Catalina represents the entire servlet container architecture, including all of the above components, as well as the security, session, cluster, deployment, management, and other servlet container components that have not yet been addressed. It integrates the Coyoto in a loosely coupled manner to complete the data reading and writing according to the request protocol. At the same time, It also includes launch portals, shell programs, and so on.

Bootstrap is the starting entrance of Catalina.

Why is tomcat not booting through Catalina and providing bootstrap?

Looking at the Tomcat release package directory, bootstrap is not stored in the Catalina Lib directory, but instead is placed in the bin directory. Bootstrap calls the Catalina instance through reflection, completely loosely coupled with the Tomcat server, which can directly rely on the JRE to run and create a shared ClassLoader for the Tomcat application server. Used to build Catalina instances as well as the entire Tomcat server.

At this point, the basic core components of Tomcat are presented at the end, and we review the concept of components

server represents the entire servlet container, where only one Server exists for a Tomcat runtime and multiple service can exist.

The service represents a collection of linker and processors, and a linker under the same service passes the request to the processor under that service

Connector represents a linker for listening and converting socket requests, supporting different protocols and IO modes

Container represents a container component, a component that can execute a client request and return a response

Engine represents the top-level container, which is the entry for the target container

Host represents a virtual machine in the servlet engine that provides domain name information such as Host

context represents a web App contextual environment

Wrapper specific servlet wrapper classes

Executor Shared thread pool between components

Tomcat Boot and request response

Tomcat class Loader

Application servers typically create their own class loaders for more flexible control, an implementation of the specification (the servlet specification requires a separate class loader instance for each Web application), and an architectural dimension.

In the book P46 the class loader is explained in detail

The JVM provides three ClassLoader for class loading by default, and Tomcat expands on the loader to load classes that apply itself.

Bootstrap The JVM provides the underlying run class that loads the JVM run, the core class library located in the%java_home%/jre/lib directory

Extension JVM provides, load extension class libraries under the%java_home%/jre/lib/ext directory

System Supplied by the JVM, loading the jar package specified in the specified directory or-classpath run parameter classpath

The bootstrap class of Tomcat is loaded by this loader

Common is the parent class loader for the system, and is the common ClassLoader on the top level of the Tomcat application server.

Its path common.loader, which points to the $catalina_home/lib directory by default.

Catalina The ClassLoader used to load the Tomcat application server with the path Server.loader,

The default is null, at which time Tomcat uses the common ClassLoader to load the application server.

Shared All Web app's ClassLoader, path shared.loader, default null.

At this point, use the common class loader as the parent loader for your web app.

The Web App loads the uncompressed class and resource files in the Web-inf/classes directory and the jar packages under the/web-inf/lib directory.

The ClassLoader is visible to the current web app and is not visible to other web apps.

Server: Apache Tomcat-Understanding the architecture hierarchy