A brief discussion on the design of Tomcat multi-layer container

Tomcat's container is used to load Servlet. So how is Tomcat's Servlet container designed?

Container Hierarchy

Tomcat has designed four containers: Engine, Host, Context and Wrapper

Through this layering, Tomcat makes the Servlet container very flexible.

• Context represents a web application
• Wrapper represents a Servlet. There may be multiple Servlets in a Web application.
• Host represents a virtual host or a site. You can configure multiple virtual host addresses for Tomcat, and multiple web applications can be deployed under a virtual host.
• Engine represents the engine, which is used to manage multiple virtual sites. A Service can have at most one Engine.
  

Observe the server.xml configuration file of Tomcat. Tomcat adopts a componentized design, with the outermost layer being the Server

These containers have a parent-child relationship, forming a tree structure. Tomcat uses a composite mode to manage these containers.

All container components implement the Container interface, so the composite mode allows users to

The lowest level wrapper of a single container object

Context, Host or Engine on the composite container object
Use of is consistent.

Container interface definition:

public interface Container extends Lifecycle {
    public void setName(String name);
    public Container getParent();
    public void setParent(Container container);
    public void addChild(Container child);
    public void removeChild(Container child);
    public Container findChild(String name);
}

The process of requesting to locate the Servlet

With so many levels of containers, how does Tomcat determine which Servlet in which Wrapper container handles the request?
Tomcat uses the Mapper component to accomplish this task.

Mapper locates the URL requested by the user to a Servlet

How it works

The Mapper component stores the configuration information of the Web application: the mapping relationship between the container component and the access path, such as

• Domain name configured in the Host container
• Web application path in the Context container
• Path of Servlet mapping in Wrapper container

These configuration information is a multi-level Map.

When a request comes in, the Mapper component can locate a Servlet by parsing the domain name and path in the request URL and then searching in the Map it has saved.
A request URL will ultimately locate only one Wrapper container, that is, a Servlet.

If there is an online shopping system,

• Backend management system for B-side managers
• Online shopping system for C-end users

The two systems run on the same Tomcat. To isolate their access domain names, two virtual domain names are configured:

manage.shopping.com
Administrators access Tomcat through this domain name to manage users and products. User management and product management are two separate Web applications.

user.shopping.com
C-end users use this domain name to search for products and place orders. The search function and order management are also two independent Web applications.

In this deployment, Tomcat will create a Service component and an Engine container component, create two Host sub-containers under the Engine container, and create two Context sub-containers under each Host container. Since a web application usually has multiple Servlets, Tomcat also creates multiple Wrapper sub-containers in each Context container. Each container has a corresponding access path

How does Tomcat locate a URL to a Servlet?

First, select Service and Engine according to the protocol and port number.
Each connector of Tomcat listens on a different port. For example, the default HTTP connector of Tomcat listens on port 8080 and the default AJP connector listens on port 8009. This URL accesses port 8080, so it will be received by the HTTP connector, and a connector belongs to a Service component, so the Service component is determined. In addition to multiple connectors, a Service component also has an Engine container, so once the Service is determined, the Engine is also determined.

Select Host based on domain name.
The Mapper component looks for the corresponding Host container through the domain name in the URL, such as user.shopping.com, so the Mapper finds the Host2 container.

Find the Context component based on the URL path
After the Host is determined, the Mapper matches the path of the corresponding Web application according to the URL path. For example, in the example, /order is accessed, so the Context container Context4 is found.

Finally, find the Wrapper (Servlet) based on the URL path
After the Context is determined, the Mapper finds the specific Wrapper and Servlet according to the Servlet mapping path configured in web.xml.

Servlets are not the only ones that process requests. Parent and child containers on the search path will also process the requests:

• The Adapter in the connector calls the container's Service method to execute the Servlet
• The first container to receive the request is the Engine container. After processing the request, the Engine container passes the request to its child container Host for further processing, and so on.
• Finally, the request will be passed to the Wrapper container, and the Wrapper will call the final Servlet to process it.

This calling process uses the Pipeline-Valve pipeline and the chain of responsibility model. During a request processing process, many handlers process the request in turn. Each handler is responsible for its own processing. After processing, the next handler will be called to continue processing.

Valve represents a processing point, such as permission authentication and logging.

public interface Valve {
  public Valve getNext();
  public void setNext(Valve valve);
  public void invoke(Request request, Response response)
}

Since Valve is a processing point, the invoke method is used to process the request.
Pipeline interface:

public interface Pipeline extends Contained {
  public void addValve(Valve valve);
  public Valve getBasic();
  public void setBasic(Valve valve);
  public Valve getFirst();
}

Therefore, a Valve linked list is maintained in the Pipeline, and the Valve can be inserted into the Pipeline.
There is no invoke method in Pipeline because the entire call chain is triggered by calling getNext.invoke to call the next Valve after the Valve completes its own processing.

Each container has a Pipeline object. As long as the first Valve of the Pipeline is triggered, all the Valves in the Pipeline of this container will be called. But how to chain trigger Pipelines of different containers?
For example, the Pipeline in the Engine needs to call the Pipeline in the lower-level container Host.
Pipeline has a getBasic method. This BasicValve is at the end of the Valve chain and is responsible for calling the first Valve in the Pipeline of the lower container.

The entire calling process is triggered by the Adapter in the connector, which calls the first Valve of the Engine:

Wrapper

The last Valve of the container will create a Filter chain and call the doFilter method, which will eventually be called to the service method of the Servlet.

What is the difference between Valve and Filter?

• Valve is Tomcat's private mechanism and is tightly coupled with Tomcat. Servlet API is a public standard, and all web containers including Jetty support Filter
• Valve works at the Web container level and intercepts all application requests. Servlet Filter works at the application level and only intercepts all requests for a certain web application. If you want to be an interceptor for the entire Web container, you must use Valve.

This is the end of this article about the design of Tomcat multi-layer container. For more relevant Tomcat multi-layer container content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!