Why care about the loading process of a Web application in Tomcat? I have seen the component structure diagram of Tomcat several times in previous articles, so here is a review:

Tomcat 7 Startup analysis

Those of you who have seen the previous Tomcat 7 Request analysis series know that after a browser request is sent to the Tomcat server, Eventually, according to the url path to find the corresponding actual browser to access the web application context object (the default namely org. Apache. Catalina. Core. StandardContext class instances). Such as access url for http://localhost:8080/, then will be sent to the above said the ROOT folder of web applications, the access url for http://localhost:8080/docs, The Web application represented by the Docs folder will be accessed. Therefore, you can guess that after Tomcat is started, the container must have constructed the various context objects representing the corresponding Web application.

This article explores this question. There are six threads running in the background after Tomcat is started by default:

main
http-bio-8080-Acceptor-0
http-bio-8080-AsyncTimeout
ajp-bio-8009-Acceptor-0
ajp-bio-8009-AsyncTimeout
ContainerBackgroundProcessor[StandardEngine[Catalina]]

Let’s take a look at how this thread is created. It’s actually a bit of a clue from its name, it’s called the container background handler, and it’s associated with StandardEngine, as is its creation and action.

All default container components in Tomcat 7 (StandardEngine, StandardHost, StandardContext, StandardWrapper) ) will inherit the parent class org. Apache. Catalina. Core. ContainerBase, container components in these startup will call its own internal startInternal method, Within this method usually call the superclass startInternal method (except StandardContext implementation of a class), such as org. Apache. Catalina. Core. StandardEngine startInternal method in the class:

super.startInternal()
Org. Apache. Catalina. Core. ContainerBase startInternal

LifecycleState.STARTING
Lifecycle.START_EVENT

ContainerBackgroundProcessor[
org.apache.catalina.core.StandardEngine

There is a problem, however, because both StandardEngine and StandardHost call super.startInternal(). By default, there should be two background threads, but there is only one.

Back to the org. Apache. Catalina. Core. ContainerBase threadStart method, before starting a thread code, there are two calibration conditions:

null
- 1

org.apache.catalina.core.StandardEngine

- 1
10

Now that the background thread is created, look at what the thread is doing, and then look at the start code for the thread:

The backgroundProcess method is already implemented inside ContainerBase:

Lifecycle.PERIODIC_EVENT

This is an overview of what Tomcat 7’s background processing threads do. In earlier versions of Tomcat, some background processing used to have a custom thread within each component and started. In Tomcat 5, all background processing shared the same thread.

Back to the question I’m answering in this article, how do Web applications load into containers? At the end of the ContainerBase backgroundProcess method:

fireLifecycleEvent(Lifecycle.PERIODIC_EVENT, null);  
Copy the code

A PERIODIC_EVENT event is registered with the container. Said in front of the default ContainerBackgroundProcessor [StandardEngine [Catalina]] thread regularly (the default is 10 seconds) execution Engine, the Host, the Context, the Wrapper BackgroundProcess methods for container components and other components associated with them, so a PERIODIC_EVENT is also periodically published to the Host component, Here to see a listener StandardHost will link under org. Apache. Catalina. Startup. HostConfig:

When Tomcat startup to parse the XML org. Apache. Catalina. Startup. Catalina class 386 lines: digester.addRuleSet(new HostRuleSet(“Server/Service/Engine/”))

In the addRuleInstances method of the HostRuleSet class:

Line 9 to 12, all will add a Host node org. Apache. Catalina. Startup. HostConfig object as org. Apache. Catalina. Core. The listener StandardHost objects

You can see in HostConfig’s lifecycleEvent method what will happen if the Host component receives a publication of the Lifecycle.PERIODIC_EVENT event (if for Tomcat 7’s Lifecycle) (5) Lifecycle mechanism and implementation principle:

PERIODIC_EVENT
START_EVENT

Mentioned earlier in this article by default components will be released when to start a Lifecycle START_EVENT events (in org. Apache. Catalina. Core. ContainerBase startInternal method the penultimate line), Back in HostConfig’s lifecycleEvent method, so the default startup will execute HostConfig’s start method, at the end of which:

if (host.getDeployOnStartup())  
    deployApps();
Copy the code

Because the default host.getDeployOnStartup() returns true, the container loads the corresponding Web application directly at startup time.

Of course, if the deployOnStartup attribute of the Host node in server.xml is set to false, the container does not load the application when it is started and cannot provide web application services immediately after it is started. But because the background thread mentioned above is running, HostConfig’s check method is periodically executed: