Hot deployment and hot loading are similar in that they enable the latest application code to take effect without restarting Tomcat. Hot deployment redeploys applications. Its execution principal is Host, indicating the Host. Hot loading means reloading the class, and its execution body is Context, which represents the application.

Background threads in Tomcat

In addition, I sorted out the interview questions for 20 years, including Spring, concurrency, database, Redis, distributed, Dubbo, JVM, microservices and other aspects of the summary, if you need to click on their own:Tencent document

Both hot deployment and hot loading need to listen for changes to the corresponding files or folders. They are all triggered by Tomcat’s background thread.

A BackgroundProcessor is a background thread.

Each container can have a BackgroundProcessor, but by default only the Engine container starts a BackgroundProcessor thread at startup.

The thread executes background tasks at intervals (unit: second). It first executes background tasks defined by the current container and then executes background tasks defined by its subcontainers. After the subcontainers finish executing tasks, the thread continues to execute tasks defined by its subcontainers until no subcontainers are available. It can be seen from this that even if each container starts a BackgroundProcessor by itself, it is only one more thread to perform the same task, and the task execution efficiency is improved.

For background tasks, there are some common tasks that all containers need to perform:

  1. Cluster Server Heartbeat
  2. If a container has its own class loader, see if it needs to be hot loaded
  3. Check whether the Session expires
  4. Executes background tasks for each container’s Realm
  5. Perform background tasks for each valve in the pipeline in each container
  6. Publish PERIODIC_EVENT events

Hot loading is triggered at step 2 and hot deployment is triggered at step 6 of the process.

Two, hot loading

We can set the reloadable property to true on the Context to indicate that the application is hot loaded. The default is false. Hot loading is triggered when files in web-INF /classes are changed, and jar packages in web-INF /lib are added, deleted, or modified.

The general hot loading process is as follows:

  1. Sets the flag that the current Context cannot accept and process requests to true
  2. Stop the current Context
  3. Start the current Context
  4. Sets the flag that the current Context cannot accept and process requests to false

Let’s focus on steps 2 and 3.

Let’s start with step 3 – what happens when the current Context is launched:

  1. Create a WebappClassLoader that is individually customized for each application
  2. Parsing the web. XML file, this step does a lot of things, but the main purpose is to find the defined Servlet and add it to the Context. The second is to look for classes that have the @webServlet annotation added to the class file. The Servlet class will be loaded later in the process, so we need to see if there is a @webServlet annotation on a class. Should we load this class first? Instead of doing this, Tomcat treats the class file as a normal file and then looks to see if there is a WebServlet annotation in the file. If there is, the class file is considered a Servlet. The class’s full name is then encapsulated in the Servlet object, which is then added to the Context object. Similarly when parsing web.xml, we end up generating a Servlet object for our defined Servlet, recording the full name of the Servlet object’s corresponding class, and adding the Servlet object to the Context.
  3. There are other annotations that we use with servlets, such as @servletSecurity, @runas, and so on. These annotations have specific functionality, and Tomcat needs to actually load our Servlet class in order to recognize this annotation. Of course, it is configurable to recognize or not recognize these annotations; if not, this step does not happen, and the Servlet class is loaded only when the request comes in.

Loading the class process:

  1. The class is loaded by calling the loadClass method of WebappClassLoaderBase, which passes the fully qualified name of a class.
  2. To load a class, you need to find out where the class is and which classs file it belongs to, so Tomcat has a cache object that holds the resource path corresponding to the fully qualified name of a class. Of course, the cache is empty the first time the class is loaded, so you need to find the class file address and then cache it. Let’s look at how to find the class file address.
  3. It is easy to find the class in web-INF /classes. If not, check whether the class exists in the web-INF /lib/ JAR. If found, the class will be cached to save the class file address or JAR address of the fully qualified name.
  4. When we know where the class is, we can defineClass and get a class object. We also set the class object in our cache, so in the cache above, there is a mapping between the fully qualified name of a class and the file address of that class and the class object of that class.
  5. So the next time you need to load a class, you can simply fetch the corresponding class object from the cache.

This is step 3, let’s look at step 2:

For step 2, stop the current Context, there is a simple task to be done, which is to clear and destroy the Context. Related to class loading is to clear the cache object mentioned above.

In this way, our heat load is empty everything first, and then restart the we applied, but because of the trigger condition is basically a class class has changed, so the process of thermal loading on application of some of the other attributes is no change, such as you now want to add in the Context of a Vavle will not trigger heat load, Hot deployment is needed to achieve this effect.

Note: Although we found in the hot loading process that it stopped and then started, which seemed rude, it was cost-effective and at least a lot more efficient than restarting Tomcat. Note: Hot loading cannot be used for WAR packages

One thing to note about class loading is that for A class represented by A class file, different instances of the same classloader can load that class and get different class objects. Back to hot loading, let’s take an example. We now have A class A, A custom WebappClassloader class starts with A WebappClassloader instance. Then there is A class object of class A in the JVM, which is hot loaded, stopped, and started. It kills all threads of the current application (except the threads that actually execute the code) on stop, and generates A WebappClassloader instance to load class A, if the class object of class A has not been recycled before hot loading. There are actually two Class objects of class A in the JVM. This is non-conflicting because the only sign of A class object is the classloader instance object + the fully qualified name of the class.

Three, hot deployment

The BackgroundProcessor thread issues a PERIODIC_EVENT in step 6, which HostConfig listens for and performs hot deployment checks and operations when it receives this event.

For applications deployed in a folder, the following resources are typically checked for changes:

  • /tomcat-7/webapps/ Application name.war
  • / tomcat/webapps/application name
  • /tomcat-7/webapps/ application name/meta-INF /context.xml
  • / tomcat 7 / conf/Catalina/localhost/application name. XML
  • /tomcat-7/conf/context.xml

For a War deployed application, the following resources are checked for changes:

  • /tomcat-7/webapps/ Application name.war
  • / tomcat 7 / conf/Catalina/localhost/application name. XML
  • /tomcat-7/conf/context.xml

For an application deployed with a descriptor, the following resources are checked for changes:

  • / tomcat 7 / conf/Catalina/localhost/application name. XML
  • Specifies the DocBase directory
  • /tomcat-7/conf/context.xml

Once these files or directories are changed, hot deployment is triggered. Of course, hot deployment is turned on by default on Host. It is important to note that Tomcat only determines whether the change time of a directory has changed, so there is no conflict with hot loading, because hot loading listens for web-INF /classes and WEB-INF/lib, while hot deployment listens for directories at the application name level.

Before we talk about the hot deployment process, let’s talk about application deployment priorities. For an application, we can define it in four areas:

  1. Context node in server.xml
  2. / tomcat 7 / conf/Catalina/localhost/application name. XML
  3. /tomcat-7/webapps/ Application name.war
  4. / tomcat/webapps/application name

The priority is the order listed above, meaning the same application name. If you configure the same application name in all four places, the lower priority will not take effect. When deploying an application, Tomcat checks whether the application name has already been deployed.

Hot deployment process: If the folder is changed, such as /tomcat-7/webapps/ application name, then nothing is done except to update the recorded change time. This is because the files in the /tomcat-7/webapps/ application name directory are either JSP files or other files. Tomcat only takes care of JSP files, and if JSP files are modified, JSP’s own mechanism will handle the modification.

If the change is/tomcat 7 / conf/Catalina/localhost/application name. XML file, then undeploy first, and then deploy, and thermal loading is similar. This includes stopping and destroying the current application, and then removing the current application from the deployed list by calling deployApps() to redeploy the application.