Tomcat container application thread pool isolation method and device based on Java Agent and medium

Abstract

The invention discloses a Tomcat container application thread pool isolation method and device based on Java Agent and a medium, and relates to the technical field of Java. The method comprises the steps that when a Tomcat container is started, an agent program is loaded through a Java Agent mechanism, and the agent program initializes a global application thread pool manager; byte code conversion is carried out on the network request processing class of the Tomcat container through the agent program, and a routing code is inserted into a request processing method of the network request processing class; creating a corresponding independent thread pool for each Web application deployed in the Tomcat container through an application thread pool manager; when an HTTP request is received, obtaining a Web application identifier to which the HTTP request belongs through the routing code; obtaining a corresponding independent thread pool from an application thread pool manager according to the Web application identifier; the processing task of the HTTP request is submitted to the obtained independent thread pool to be executed, the processing task is prevented from being executed in the original shared thread pool of the Tomcat container, and therefore multi-application thread pool isolation in the Tomcat container can be achieved in a non-intrusive mode.

Description

Technical Field

[0001] This invention relates to the field of Java technology, and in particular to a method, device, and medium for isolating thread pools in Tomcat container applications based on a Java Agent. Background Technology

[0002] Apache Tomcat, a widely used open-source Java web application server, is commonly deployed in microservice architectures and cloud-native environments to save resources and simplify operations and maintenance. This often involves deploying multiple applications on a single Tomcat instance, i.e., multiple independent WAR application packages within a single Tomcat instance. In this deployment mode, all web applications share a common thread pool in the Tomcat connector, and all HTTP requests are processed using threads allocated from this common thread pool. The inventors of this application have discovered that this sharing mechanism causes significant resource isolation problems, the most critical of which is the "noisy neighbor" effect. When an application experiences slow request processing due to code defects, external interface delays, or malicious attacks, a large number of worker threads are occupied by that application for an extended period, quickly exhausting the thread pool resources. This causes requests from other healthy applications within the same instance to wait or be rejected due to the inability to obtain threads, ultimately triggering a cascading failure across the entire Tomcat instance, resulting in the severe consequence of one application dragging down all services.

[0003] Furthermore, the shared model described above also gives rise to multiple resource management challenges. All applications compete for resources in the same thread pool queue, and high-traffic applications may crowd out threads from low-traffic applications, making differentiated scheduling based on service level agreements (SLAs) impossible. When the thread pool runs out or response time spikes, existing monitoring metrics are global, making it difficult for operations personnel to quickly pinpoint the specific application causing the problem. Moreover, the shared model prevents setting independent thread pool parameters for individual applications, making it impossible to allocate more threads to critical applications or restrict thread usage for non-critical applications, which violates the principle of independent service deployment and scaling in microservice architectures.

[0004] Existing solutions to address the aforementioned issues have significant drawbacks. While physically or virtually isolating each application by deploying a separate Tomcat instance achieves complete isolation, it incurs substantial resource overhead and operational costs, contradicting the trend towards high-density deployments. Furthermore, although containerized isolation is lighter than virtual machines, it still incurs multiple JVM overheads, and thread-level isolation issues remain unresolved at the application server level. Finally, modifying the Tomcat source code suffers from strong intrusion, version-specific coupling, lack of access to community updates, and complex deployment. Summary of the Invention

[0005] This invention provides a method, device, and medium for isolating application thread pools in a Tomcat container based on a Java Agent, aiming to solve the technical problem of how to achieve non-intrusive isolation of multiple application thread pools within a Tomcat container.

[0006] In a first aspect, embodiments of the present invention provide a Tomcat container application thread pool isolation method based on a Java Agent, comprising: When the Tomcat container starts, the agent program is loaded through the Java Agent mechanism, and the agent program initializes a global application thread pool manager; The proxy program performs bytecode conversion on the network request processing class of the Tomcat container and inserts routing code into the request processing method of the network request processing class. The application thread pool manager creates a corresponding independent thread pool for each web application deployed in the Tomcat container; When an HTTP request is received, the web application identifier to which the HTTP request belongs is obtained through the routing code; Obtain the corresponding independent thread pool from the application thread pool manager based on the web application identifier; The HTTP request processing task is submitted to the obtained independent thread pool for execution, and the routing code prevents the processing task from being submitted to the Tomcat container's original shared thread pool; wherein, when the processing task is executed in the independent thread pool, the original processing flow of the processing task is directly executed.

[0007] Optionally, the step of creating a corresponding independent thread pool for each web application deployed in the Tomcat container through the application thread pool manager includes: Parse the external configuration file and read the thread pool parameters corresponding to each Web application identifier from the external configuration file; The application thread pool manager creates a corresponding independent thread pool for each web application based on the thread pool parameters.

[0008] Optionally, the step of performing bytecode conversion on the Tomcat container's network request processing class through the proxy program, and inserting routing code into the request processing method of the network request processing class, includes: Identify the endpoint handling class responsible for handling network sockets in the connector component of the Tomcat container; Insert the routing code at the entry point of the execution method of the internal task class of the endpoint processing class.

[0009] Optionally, the step of creating a corresponding independent thread pool for each web application through the application thread pool manager according to the thread pool parameters includes: When an HTTP request for any web application is received for the first time, the application thread pool manager creates an independent thread pool instance based on the Java concurrency package thread pool implementation according to the thread pool parameters corresponding to the web application identifier. The created independent thread pool instance is associated with the web application identifier and stored in the mapping relationship of the application thread pool manager, so as to serve as the independent thread pool corresponding to the web application.

[0010] Optionally, obtaining the corresponding independent thread pool from the application thread pool manager based on the Web application identifier includes: Using the Web application identifier as the key, a search is performed in the mapping relationship of the application thread pool manager to obtain an independent thread pool instance stored in association with the Web application identifier.

[0011] Optionally, obtaining the web application identifier to which the HTTP request belongs through the routing code includes: The context path is parsed from the internal request object corresponding to the HTTP request by inserting the routing code, and the context path is used as the identifier of the web application.

[0012] Optionally, preventing the processing task from executing in the Tomcat container's original shared thread pool includes: After the processing task is submitted to the obtained independent thread pool, the execution flow of the request processing method is terminated by the routing code to skip the remaining logic in the request processing method used to submit the processing task to the Tomcat original shared thread pool.

[0013] Optionally, it also includes: When submitting the HTTP request processing task to the independent thread pool, the Web application identifier is encapsulated into the task object to be executed; When a worker thread in the independent thread pool executes the task object, it retrieves the Web application identifier from the task object and binds the Web application identifier to the thread-local storage of the worker thread. After the task object has been executed, the Web application identifier is removed from the thread-local storage of the worker thread.

[0014] Secondly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0015] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0016] This invention provides a method, device, and medium for isolating application thread pools in a Tomcat container based on a Java Agent. The method includes: when the Tomcat container starts, loading an agent program via a Java Agent mechanism; the agent program initializing a global application thread pool manager; performing bytecode conversion on the Tomcat container's network request processing class via the agent program, inserting routing code into the request processing method of the network request processing class; creating a corresponding independent thread pool for each web application deployed in the Tomcat container through the application thread pool manager; when an HTTP request is received, obtaining the web application identifier to which the HTTP request belongs through the routing code; obtaining the corresponding independent thread pool from the application thread pool manager based on the web application identifier; submitting the HTTP request processing task to the obtained independent thread pool for execution, and preventing the processing task from being submitted to the Tomcat container's original shared thread pool through the routing code; wherein, when the processing task is executed in the independent thread pool, the original processing flow of the processing task is directly executed. This invention loads an agent program during Tomcat container startup using a Java Agent mechanism. It non-intrusively converts the bytecode of network request processing classes and inserts routing code without modifying the Tomcat source code or application code. By creating an independent thread pool for each web application, the routing code submits processing tasks to the corresponding independent thread pool based on the web application identifier of the request, preventing execution in the original shared thread pool. This achieves physical isolation of thread pool resources among multiple applications within a single Tomcat instance. This isolation mechanism fundamentally eliminates the "noise neighbor effect"—where a thread pool exhaustion due to a failure or high load in one application affects other applications in the same instance—preventing cascading failures. Furthermore, the establishment of independent thread pools for each application allows for individual monitoring of thread usage, laying the foundation for fine-grained resource management and fault localization at the application level, significantly improving the overall stability, reliability, and maintainability of the Tomcat container. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a Tomcat container application thread pool isolation method based on a Java Agent, provided in an embodiment of the present invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0021] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0022] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0024] Please see Figure 1 This invention provides a method for isolating thread pools in Tomcat containers based on a Java Agent, the method comprising the following steps: S1. When the Tomcat container starts, the agent program is loaded through the Java Agent mechanism, and the agent program initializes a global application thread pool manager.

[0025] In practice, the agent program is loaded via the Java Agent mechanism when the Tomcat container starts. JavaAgent is a mechanism provided by the Java platform that allows specific agent code to be loaded and run during JVM startup. Implementing this mechanism requires pre-building a JAR file containing the agent class and specifying `PremainClass` in the `MANIFEST.MF` file of that JAR file. In the Tomcat container's startup script, the `javaagent` directive is added via the `JAVA_OPTS` parameter, specifying the path to the JAR file. When the JVM initializes, the `premain` method of the agent class is called, thus completing the loading of the agent program. During the execution of the `premain` method, the agent program can obtain an instance of the `Instrumentation` interface, which provides the ability to modify bytecode during class loading.

[0026] For ease of description, the term "agent program loaded through the Java Agent mechanism" will be referred to as "agent program" in the following text. This term has the same meaning as "Java Agent" and "agent class" in this invention, and all refer to the program module loaded through the JavaAgent mechanism and used to implement the thread pool isolation function.

[0027] After the agent is loaded, it performs initialization operations, creating a global application thread pool manager. The application thread pool manager is a singleton object implemented internally by the agent, responsible for all thread pool-related management functions throughout its lifecycle. Upon creation, the application thread pool manager initializes its internal data structures, including a concurrent hash map storing the mapping between web application identifiers and independent thread pools, as well as auxiliary structures for statistics and monitoring. The application thread pool manager provides a series of methods, including methods for obtaining independent thread pools based on web application identifiers, creating independent thread pools, updating thread pool parameters, and destroying thread pools.

[0028] S2, the proxy program performs bytecode conversion on the network request processing class of the Tomcat container and inserts routing code into the request processing method of the network request processing class.

[0029] In practice, a proxy program performs bytecode conversion on the network request handling classes of the Tomcat container. The proxy program uses the `addTransformer` method provided by the Java Instrumentation API to register a custom class file converter with the JVM.

[0030] This file converter implements the `ClassFileTransformer` interface and overrides its `transform` method. When the Tomcat container starts and loads its core classes, the JVM calls the `transform` method of the registered converters, passing the bytecode of the class to be loaded as a parameter. Within the `transform` method, the converter checks if the currently loaded class is the target class. If so, it modifies the bytecode of that class, inserts custom routing code, and then returns the modified bytecode to the JVM, which loads the modified class. The bytecode transformation operation is performed only once during the class loading phase; classes that have already been loaded are not transformed repeatedly.

[0031] In some preferred embodiments, the step of performing bytecode conversion on the network request processing class of the Tomcat container through the proxy program and inserting routing code into the request processing method of the network request processing class includes: identifying the endpoint processing class responsible for handling network sockets in the connector component of the Tomcat container; and inserting the routing code at the entry point of the execution method of the internal task class of the endpoint processing class.

[0032] In practice, the proxy program performs bytecode conversion on the network request handling class of the Tomcat container and inserts routing code into the request handling method of the network request handling class. This is achieved through the following steps.

[0033] First, the agent identifies the endpoint handling class responsible for handling network sockets within the Tomcat container's connector component. In Tomcat's architecture, the connector component handles network communication, and different I / O models correspond to different connector implementations, such as NIO Endpoint, APR Endpoint, and NIO2 Endpoint. These implementations all inherit from the `org.apache.tomcat.util.net.AbstractEndpoint` abstract class, which defines the basic framework for endpoint handling.

[0034] Furthermore, each endpoint implementation class contains one or more internal task classes to handle requests received on the network socket. For example, NioEndpoint defines a private static inner class named SocketProcessor, which implements the Runnable interface and is responsible for handling requests from a specific socket.

[0035] Furthermore, when the connector receives a new request, it creates a SocketProcessor instance and submits it to the thread pool for execution. After identifying the endpoint handling class, the agent inserts routing code at the entry point of the run method in the inner task class of the endpoint handling class. The run method, implemented in the inner task class, is one of the core entry points for Tomcat to process each HTTP request.

[0036] Furthermore, when the agent's class file converter detects that the target's internal task class is loaded, it obtains the bytecode of that class and inserts custom bytecode instructions at the beginning of its run method.

[0037] Furthermore, the inserted bytecode instructions perform the following functions: obtain the context path of the current request, call the application thread pool manager to obtain the corresponding independent thread pool, submit the current task to the independent thread pool, and then return early to prevent the original logic from executing. After insertion, the class file converter returns the modified bytecode to the JVM, which loads and executes the enhanced class.

[0038] This embodiment achieves precise interception of critical paths in Tomcat request processing by inserting routing code at the entry point of the execution method in the inner task class of the endpoint processing class. This interception point is located in the earliest stage of Tomcat request processing, specifically after the request has been read from the network socket and encapsulated into a task object, but before it enters the Servlet container for processing. Inserting routing code at this stage ensures that all HTTP requests entering Tomcat are captured without omission, while avoiding the complexity and performance overhead that might arise from interception at higher levels. Furthermore, since the interception point is located within the inner task class, the inserted routing code can directly access fields of the task object, such as fields encapsulating socket and request information, thus facilitating the subsequent acquisition of the Web application identifier. For example, the inner request object can be obtained from the task object via reflection, and then the context path can be obtained from the request object. This bytecode enhancement method targeting a specific inner class ensures both the comprehensiveness and accuracy of the interception while avoiding excessive enhancement that could impact other unrelated functional modules of Tomcat.

[0039] S3, the application thread pool manager creates a corresponding independent thread pool for each web application deployed in the Tomcat container.

[0040] In practice, an independent thread pool is created for each web application deployed in the Tomcat container through an application thread pool manager. During the Tomcat container startup process, it scans and deploys all WAR application packages placed in the webapps directory. Each application corresponds to a StandardContext instance, and each StandardContext instance has a unique context path.

[0041] Furthermore, the application thread pool manager obtains a list of context paths for the deployed web application, for example, by accessing service objects inside Tomcat through reflection or by parsing Tomcat's configuration files.

[0042] Furthermore, for each acquired web application, the application thread pool manager creates a separate java.util.concurrent.ThreadPoolExecutor instance. This instance has its own task queue, its own set of threads, and its own thread management mechanism.

[0043] Furthermore, during the creation process, the application thread pool manager configures corresponding parameters for each thread pool. These parameters can be read from a configuration file or use preset default values. Specific parameters include: core thread count (the number of threads that are always alive in the thread pool); maximum thread count (the maximum number of threads the thread pool is allowed to create); thread idle lifespan (the maximum lifespan of idle threads when the number of threads exceeds the core thread count); task queue (used to store tasks waiting to be executed, which can be a bounded or unbounded queue); thread factory (used to create new threads, which can have custom thread names for easy identification); and rejection policy (the handling strategy executed when a task cannot be accepted).

[0044] In some preferred embodiments, the step of creating a corresponding independent thread pool for each web application deployed in the Tomcat container through the application thread pool manager includes: parsing an external configuration file, reading thread pool parameters corresponding to each web application identifier from the external configuration file, and creating a corresponding independent thread pool for each web application through the application thread pool manager according to the thread pool parameters.

[0045] In practice, the application thread pool manager creates a corresponding independent thread pool for each web application deployed in the Tomcat container, which is achieved through the following steps.

[0046] First, the application thread pool manager parses the external configuration file. The external configuration file is a text file independent of the application and Tomcat, typically placed in Tomcat's conf directory or specified via a javaagent parameter. This file can be in common formats such as properties, YAML, or JSON, making it easy for operations and maintenance personnel to edit and maintain.

[0047] Furthermore, during the initialization phase, the application thread pool manager opens the file using Java's file reading API and uses the corresponding parser to parse the file content into an in-memory data structure. After parsing, the application thread pool manager reads the thread pool parameters corresponding to each web application identifier from this data structure. The thread pool parameters exist in key-value pairs, where the key is the web application identifier, such as the context path / app1, and the value is a collection containing multiple parameter items.

[0048] Furthermore, the parameters specifically include: core thread count, which specifies the minimum number of threads that must always remain alive in the thread pool; maximum thread count, which specifies the maximum number of threads that the thread pool is allowed to create, and tasks exceeding this number will enter the waiting queue or be rejected; task queue capacity, which specifies the maximum length of the waiting queue, and new tasks will trigger the rejection policy when the queue is full; thread idle lifespan, which specifies the time that idle threads exceeding the core thread count can remain idle before being reclaimed; and rejection policy, which specifies the handling method when a task cannot be accepted, such as throwing an exception, having the caller thread execute the task, or discarding the task.

[0049] Furthermore, the application thread pool manager creates a corresponding independent thread pool for each web application based on the read thread pool parameters. During creation, the application thread pool manager instantiates a java.util.concurrent.ThreadPoolExecutor object using the parameter values ​​obtained from the configuration file. For web applications that do not explicitly specify parameters in the configuration file, the application thread pool manager uses preset default parameter values ​​to ensure that each web application obtains a properly configured independent thread pool.

[0050] This embodiment achieves fine-grained configuration management of thread pool resources by parsing external configuration files to independently specify thread pool parameters for each web application. In real-world production environments, different web applications have different business importance and load characteristics. For example, core transaction systems require high concurrency processing capabilities, while backend reporting systems have lower response time requirements. Through configuration files, operations personnel can allocate more core threads and larger queue capacities to critical applications to ensure they can handle sudden traffic surges during peak periods; and allocate fewer thread resources to non-critical applications to prevent them from excessively consuming system resources. This differentiated configuration approach ensures that the allocation of thread pool resources precisely matches business needs, avoiding resource waste or performance issues caused by all applications using the same thread pool parameters in the traditional shared thread pool model. Furthermore, configuring thread pool parameters in an external file means that parameter adjustments do not require recompiling the code; only modifying the configuration file and restarting Tomcat takes effect, improving the flexibility and convenience of operations. Moreover, the configuration file format is easy to read and modify, reducing the learning cost for operations personnel.

[0051] In some preferred embodiments, the step of creating a corresponding independent thread pool for each Web application by the application thread pool manager according to the thread pool parameters includes: when an HTTP request for any Web application is received for the first time, the application thread pool manager creates an independent thread pool instance based on the Java concurrency package thread pool implementation according to the thread pool parameters corresponding to the Web application identifier; and associates the created independent thread pool instance with the Web application identifier in the mapping relationship of the application thread pool manager, so as to serve as the independent thread pool corresponding to the Web application.

[0052] In practice, an independent thread pool is created for each web application deployed in the Tomcat container through the application thread pool manager, which is achieved through the following steps.

[0053] When an HTTP request for any web application is received for the first time, the application thread pool manager creates an independent thread pool instance based on the thread pool parameters corresponding to the web application identifier. Internally, the application thread pool manager maintains a concurrent hash map to store the association between web application identifiers and independent thread pool instances. When the routing code calls the application thread pool manager's get method, passing in the web application identifier, the application thread pool manager first performs a lookup operation in the map using that identifier as the key. If no corresponding entry is found in the map, it indicates that this is the first time the web application has received a request, and a thread pool needs to be created.

[0054] Furthermore, the application thread pool manager retrieves the corresponding thread pool parameters from the internally stored configuration information based on the web application identifier. This configuration information is parsed from an external configuration file and loaded into memory during agent initialization, and is stored as key-value pairs. After retrieving the thread pool parameters, the application thread pool manager uses these parameters to instantiate java.util.concurrent.ThreadPoolExecutor objects.

[0055] Furthermore, during instantiation, the application thread pool manager uses a custom thread factory to assign names containing the web application identifier to the created threads, facilitating subsequent monitoring and troubleshooting. Once creation is complete, the application thread pool manager stores the newly created independent thread pool instance and the current web application identifier as key-value pairs in its internally maintained concurrent hash map.

[0056] Furthermore, after the data is stored, the mapping will contain the relationship between the web application identifier and its independent thread pool instance. Subsequent query requests for the same web application identifier will directly return the existing instance from the mapping. Finally, the application thread pool manager returns the newly created independent thread pool instance to the caller, i.e., the routing code. After obtaining the instance, the routing code can submit the processing task of the current HTTP request to this thread pool for execution.

[0057] This embodiment uses a lazy loading approach triggered by the first request to create independent thread pools, avoiding the resource waste caused by pre-creating thread pools for all deployed web applications when Tomcat starts. In a real production environment, a Tomcat instance may deploy dozens or even hundreds of web applications, but not all applications have access traffic simultaneously; many applications may remain idle for extended periods. If a pre-creation approach is used, thread pools for all applications will be created and consume memory resources at startup, including the thread pool objects themselves, task queues, and pre-started core threads, leading to significant resource idleness and waste. Furthermore, through the lazy loading mechanism, only web applications that actually receive requests will create thread pools and consume resources, while unaccessed applications will not consume any thread pool resources. This on-demand creation method significantly reduces the resource overhead during Tomcat startup and improves system resource utilization. Furthermore, associating independent thread pool instances with web application identifiers in a mapping relationship provides efficient routing lookup support for subsequent requests. The system creates and stores resources on the first request, and then retrieves and reuses them on subsequent requests. This design ensures both on-demand resource allocation and efficient processing of subsequent requests.

[0058] S4. When an HTTP request is received, the Web application identifier to which the HTTP request belongs is obtained through the routing code.

[0059] In practice, when the Tomcat container receives an HTTP request, the request first enters Tomcat's network request handling class for processing. Tomcat uses the connector component to handle network communication, which contains multiple processing stages. Upon arrival of the request, the connector component reads data from the network socket, parses the HTTP request line and headers, and encapsulates them into an internal request object. Subsequently, the connector component hands this internal request object to a handler for processing, which is typically executed in a single thread. Because the network request handling class has been bytecode-transformed and have routing code inserted, when an enhanced method is executed, the inserted routing code is executed first.

[0060] Furthermore, the routing code retrieves the web application identifier to which the HTTP request belongs. The routing code is inserted at the beginning of the request handling method, so it runs before any business logic is executed. The routing code needs to obtain information about the web application to which the currently processed HTTP request belongs.

[0061] Furthermore, in Tomcat's implementation, each HTTP request is internally represented as an `org.apache.catalina.connector.Request` object. This object contains all the request information, including the request URI, headers, parameters, etc. The routing code obtains a reference to this internal request object through the current execution context. The method of obtaining this object depends on the enhanced class and the location of the inserted code. For example, it can be obtained by retrieving the object encapsulating the request information from a field of the enhanced class (such as `SocketProcessor`), or by calling a known method. After obtaining the internal request object, the routing code calls methods of that object to retrieve the context path.

[0062] Furthermore, the context path is the deployment path of the web application in Tomcat. For example, an application deployed in the webapps / ROOT directory has an empty context path, while an application deployed in the webapps / app1 directory has a context path of / app1. Tomcat's internal request object provides methods to obtain the context path, such as by calling request.getContext().getPath(). The routing code executes this method to obtain the context path of the web application to which the current request belongs, and saves this string as the web application identifier for use in subsequent steps.

[0063] In some preferred embodiments, obtaining the Web application identifier to which the HTTP request belongs through the routing code includes: parsing the context path from the internal request object corresponding to the HTTP request through the inserted routing code, and using the context path as the Web application identifier.

[0064] In practice, the identifier of the web application to which the HTTP request belongs is obtained through the routing code, which is achieved through the following steps.

[0065] The routing code is inserted into the request handling method of the Tomcat network request handling class. When this method is called, the routing code is executed as the first instruction. The routing code first needs to obtain the internal request object corresponding to the currently processed HTTP request. In Tomcat's implementation, after the request is read and parsed from the network socket, it is encapsulated into an `org.apache.coyote.Request` object, which contains the underlying information of the request. Further, this `coyote Request` object is wrapped into an `org.apache.catalina.connector.Request` object, which is a request object provided to the upper-level Servlet container and contains more high-level APIs. The routing code can obtain this internal request object through existing fields in the enhanced class. For example, in the inner class `SocketProcessor` of `NioEndpoint`, there is usually a field holding a `SocketWrapper` object associated with the current socket, and the `SocketWrapper` object in turn holds a reference to the `coyote Request` object.

[0066] Furthermore, the routing code retrieves the coyote request object by tracing this reference chain using reflection or direct field access. Once the coyote request object is obtained, the routing code calls its methods to retrieve the request's context information. The coyote request object provides a getContext method, which returns an org.apache.catalina.Context object, representing the web application context to which the current request belongs.

[0067] Next, the routing code calls the `getPath` method of the `Context` object, which returns the context path string of the current web application. The context path is the deployment path of the web application in Tomcat; for example, the root application returns an empty string, and the application ` / app1` returns the string ` / app1`. After obtaining this string, the routing code stores it as the web application identifier in a local variable for use in subsequent steps. If any exception occurs during this process, such as reflection failure or obtaining a null object, the routing code will catch the exception and log it. Then, following the fallback mechanism, the request will continue to be handled by Tomcat's original logic, ensuring that request processing does not fail due to exceptions in the routing code.

[0068] This embodiment obtains the web application identifier by parsing the context path from the internal request object, ensuring the accuracy and reliability of the identifier acquisition. The context path is a standardized attribute natively provided by the Tomcat container to distinguish different web applications; each web application is assigned a unique context path during deployment. Using this attribute as the identifier avoids compatibility issues that may arise from introducing custom identifiers, such as the need to maintain additional application identifier mapping tables or modify application deployment configurations. Furthermore, the routing code directly utilizes methods provided by the Tomcat internal object to obtain this attribute, eliminating the need for additional parsing logic or maintaining external mapping relationships, simplifying implementation complexity and reducing the probability of errors. Furthermore, since the context path is directly related to the URI path of the HTTP request, this method accurately reflects the web application to which the request belongs. Regardless of how the specific URL of the request changes, as long as its URI prefix matches the context path, it can be correctly identified. For example, requests to / app1 / index.html and / app1 / api / user can both be correctly identified as belonging to the / app1 application. This identification method based on native container attributes ensures the universality and stability of the identifier acquisition process.

[0069] S5. Obtain the corresponding independent thread pool from the application thread pool manager according to the Web application identifier.

[0070] In practice, the corresponding independent thread pool is retrieved from the application thread pool manager based on the web application identifier. After obtaining the web application identifier, the routing code calls the application thread pool manager's retrieval method, passing the identifier as a parameter. Internally, the application thread pool manager maintains a concurrent hash map, with the web application identifier as the key and the corresponding independent thread pool instance as the value. Upon receiving the parameter, the application thread pool manager performs a lookup operation in the map using the identifier as the key. If an entry corresponding to the identifier exists in the map, the corresponding independent thread pool instance is retrieved and returned to the routing code. Furthermore, if no corresponding entry exists in the map, it indicates that the web application has not yet created an independent thread pool. The application thread pool manager will then trigger the thread pool creation process, creating a new independent thread pool instance based on the application's configuration parameters, storing it in the map, and returning the newly created instance.

[0071] In some preferred embodiments, obtaining the corresponding independent thread pool from the application thread pool manager based on the Web application identifier includes: using the Web application identifier as the key, searching in the mapping relationship of the application thread pool manager to obtain an independent thread pool instance stored in association with the Web application identifier.

[0072] In practice, the corresponding independent thread pool is obtained from the application thread pool manager based on the web application identifier. This is achieved through the following steps: When the routing code reaches the stage where it needs to obtain an independent thread pool, it has already obtained the web application identifier (context path string) to which the current HTTP request belongs through the aforementioned steps. Further, the routing code uses this string as a parameter to call a public method provided by the application thread pool manager, such as `getExecutor(String contextPath)`. After receiving the call request, the application thread pool manager uses the passed-in web application identifier as the key to perform a lookup operation in its internally maintained concurrent hash map.

[0073] Furthermore, this concurrent hash map is an instance of java.util.concurrent.ConcurrentHashMap, which features thread safety and high-concurrency read / write capabilities. Each entry in the map is a key-value pair, where the key is the web application identifier and the value is a reference to an independent thread pool instance.

[0074] Furthermore, the application thread pool manager calls the `get` method of `ConcurrentHashMap`, passing the web application identifier as a parameter. `ConcurrentHashMap` locates the corresponding bucket based on the hash value of the key, and then searches for an entry in the bucket that matches the key.

[0075] Furthermore, if a matching entry is found, the value corresponding to that entry is retrieved, which is a reference to the independent thread pool instance. The application thread pool manager returns this reference to the caller, i.e., the routing code.

[0076] Furthermore, if the lookup result is null, it means that there is no entry in the mapping corresponding to the web application identifier. In this case, the application thread pool manager will automatically trigger the thread pool creation process. The creation process includes obtaining the corresponding thread pool parameters based on the web application identifier, instantiating a ThreadPoolExecutor object using the parameters, storing the new instance in the mapping, and finally returning the new instance to the caller. After returning the independent thread pool instance, the routing code can use this instance to execute subsequent task submission operations.

[0077] This embodiment achieves an efficient and accurate thread pool routing mechanism by using the Web application identifier as the key to search for independent thread pool instances in the mapping relationship of the application thread pool manager. The lookup operation of ConcurrentHashMap has constant-time complexity, typically O(1), meaning that regardless of the number of Web application thread pools managed in the system, the time required for each lookup is essentially fixed and does not increase with the number of applications. This efficiency ensures that the impact of the routing process on request processing performance is minimized, and even in high-concurrency scenarios, the thread pool lookup operation will not become a performance bottleneck. Furthermore, the association between thread pool instances and Web application identifiers is centrally stored in the application thread pool manager, making the thread pool resource view of the entire system unified and clear. When it is necessary to monitor or dynamically adjust the thread pool of a specific Web application, operations personnel can quickly locate the corresponding thread pool instance using the same Web application identifier. For example, through the management interface exposed by JMX MBean, the Web application identifier can be passed in to obtain the monitoring data of the corresponding thread pool or adjust its parameters, providing convenience for subsequent operations and maintenance management.

[0078] S6, the HTTP request processing task is submitted to the obtained independent thread pool for execution, and the routing code prevents the processing task from being submitted to the original shared thread pool of the Tomcat container; wherein, when the processing task is executed in the independent thread pool, the original processing flow of the processing task is directly executed.

[0079] In practice, the HTTP request processing task is submitted to an independent thread pool for execution. Internally, the processing task is typically represented by a Runnable or Callable object, which encapsulates all the logic required to handle the HTTP request, including calls to Servlets, filters, and listeners. After the routing code obtains an instance of the independent thread pool, it calls the thread pool's `execute` or `submit` method, passing the processing task as a parameter. Upon receiving the task, the independent thread pool places it in its internal task queue. When an idle thread is available in the thread pool, it retrieves the task from the queue and executes it. During execution, the processing task calls the upper-layer business logic to complete the response to the HTTP request. Because the task is executed within a thread of an independent thread pool, its consumption of thread resources is limited to the web application's own thread pool and will not affect the thread pools of other web applications.

[0080] Furthermore, the routing code prevents the processing task from executing in the Tomcat container's original shared thread pool. The original design of the Tomcat container is that after the network request processing class completes request parsing, it submits the processing task to a global shared thread pool, which then allocates threads to execute the task. This submission logic is located in the request processing method of the network request processing class, after the routing code is inserted. To ensure that the processing task is submitted only to a separate thread pool and not to the original shared thread pool, the routing code needs to prevent the subsequent logic of the original method from executing after submitting the task to the separate thread pool. In the bytecode enhancement implementation, a return instruction can be added to the end of the inserted routing code to cause the method to return early.

[0081] For example, when using Javassist for enhancement, a `return` statement can be added to the end of the inserted code block. This way, after the routing code finishes executing, the method returns immediately, without executing any instructions in the original method body after the return point, including the code that submits the processing task to the original shared thread pool. Through this early return, the processing task is successfully redirected to an independent thread pool, and the original shared thread pool will not receive the task, thus blocking the execution path of the original shared thread pool.

[0082] Furthermore, when the processing task is executed in the independent thread pool, the original processing flow of the processing task is executed directly.

[0083] Specifically, after the routing code of this invention is inserted into the network request processing class (e.g., the run method of SocketProcessor) of the Tomcat container, it does not unconditionally perform thread pool acquisition and task redirection operations. To solve the problem of infinite loops that may be caused by re-executing tasks in an independent thread pool, this invention introduces an execution environment detection mechanism into the routing code.

[0084] When the processing task is submitted to the independent thread pool and scheduled for execution by worker threads in the pool, the routing code first checks whether the current execution environment is already within the independent thread pool. This detection can be implemented in various ways, such as, but not limited to, checking whether a preset flag exists in the current thread's thread-local storage (ThreadLocal), or checking the status flag of the current task object.

[0085] If the detection result indicates that the current execution environment already belongs to the independent thread pool (i.e., it is determined that the current execution is a secondary execution of the task in the independent thread pool), then the routing code determines that the current execution should not trigger the routing logic again, and instead directly allows and executes the original processing flow of the processing task. The original processing flow refers to the request processing logic natively defined by the Tomcat container that has not been interfered with by the routing code, such as the complete chain of calling the Servlet container to parse, filter and process HTTP requests, and this invention does not specifically limit this.

[0086] If the detection result indicates that the current execution environment does not belong to the independent thread pool (i.e., it is determined that the current execution is the first execution of the task in the Tomcat original thread pool), the routing code executes the complete redirection logic, including: obtaining the Web application identifier, obtaining the corresponding independent thread pool, submitting the processing task to the independent thread pool, and preventing it from being executed in the original shared thread pool by returning early.

[0087] Through the above mechanism, the present invention achieves the following technical effects: Eliminating circular recursion: When a task is executed in an independent thread pool, it skips the redirection logic of the routing code because it is detected that it is in an isolated environment, and directly enters the original business processing, which fundamentally avoids the infinite loop caused by the task being repeatedly submitted to the thread pool.

[0088] Clear execution path: For each HTTP request, its processing task only undergoes one route redirection (from the original thread pool to the independent thread pool), and then executes the original business logic only once in the independent thread pool, ensuring the integrity and singleness of the task lifecycle.

[0089] Non-intrusive and compatible: The detection mechanism is completely embedded in the routing code, transparent to upper-layer business applications, and requires no modification to any business code, maintaining the non-intrusive advantage of the Java Agent solution.

[0090] This embodiment achieves non-intrusive enhancement to the Tomcat container by loading a Java Agent program during container startup. The agent program is loaded during JVM initialization, requiring no modification to the Tomcat source code or recompilation of Tomcat, and no alterations to the web applications deployed in the container, thus maintaining the integrity of the original system and applications. The agent program inserts routing code into the network request handling class using bytecode transformation technology, enabling every HTTP request entering Tomcat to be intercepted and redirected. The application thread pool manager creates independent thread pool instances for each web application. These thread pool instances are isolated from each other and manage their own thread resources. When a web application experiences slow request processing due to code defects, external dependency failures, or malicious attacks, that application will only exhaust its own independent thread pool, while other web applications, having their own independent thread pool resources, can still have their requests processed normally without being affected. This isolation mechanism fundamentally eliminates the noisy neighbor effect, avoiding the risk of a single application failure causing a cascading crash of the entire Tomcat instance. Furthermore, the introduction of independent thread pools allows for individual monitoring of thread usage in each web application, such as the number of active threads, queue depth, and number of completed tasks. This provides operations personnel with fine-grained monitoring data at the application level, which helps to quickly locate problems and perform capacity planning.

[0091] In some preferred embodiments, preventing the processing task from executing in the Tomcat container's original shared thread pool includes: after the processing task is submitted to the obtained independent thread pool, terminating the execution flow of the request processing method through the routing code to skip the remaining logic in the request processing method used to submit the processing task to the Tomcat original shared thread pool.

[0092] In practice, preventing processing tasks from executing in the Tomcat container's original shared thread pool is achieved through the following steps. After a processing task is submitted to its assigned independent thread pool, the routing code needs to ensure that the task is not submitted back to Tomcat's original shared thread pool. In Tomcat's original request processing method, after the routing code is inserted, there is typically remaining logic to submit the task to the original shared thread pool.

[0093] Taking the inner class SocketProcessor of NioEndpoint as an example, the original logic of its run method includes: retrieving information from SocketWrapper, calling the processor to process the task, and then returning the processing result. The processor call ultimately submits the task to Tomcat's shared thread pool. Therefore, after the routing code submits the current SocketProcessor instance itself as a task to an independent thread pool, it's necessary to prevent the run method from continuing to execute its subsequent logic.

[0094] Furthermore, when implementing this through bytecode enhancement, an unconditional jump or return instruction can be added to the end of the inserted routing code. Specifically, when using Javassist for enhancement, a return statement can be added to the end of the inserted code block. This return statement will cause the method to return immediately, and no further instructions in the original method body following this return statement will be executed. Thus, once the routing code has finished executing and submitted the task to the independent thread pool, the run method terminates immediately, and the subsequent original logic is completely skipped. Tomcat's shared thread pool will therefore not receive this processing task.

[0095] It's important to note that since the SocketProcessor instance itself has been submitted to a separate thread pool, its `run` method will be called again within that thread pool. However, this `run` method has been enhanced, and when it executes in the separate thread pool, the routing code will be executed again. Therefore, it's necessary to avoid circular calls when executing in the separate thread pool. This can be achieved by adding conditional logic to the routing code, such as checking if the current thread is already in the separate thread pool, or checking a flag. If it's detected that the thread is already in the separate thread pool, the routing logic is skipped, and the original processing flow is executed directly. This ensures that the task can be processed normally in the separate thread pool while avoiding infinite loops.

[0096] In a preferred embodiment, circular calls can be prevented by combining a flag in thread-local storage (ThreadLocal). Specifically, when the routing code executes, it first checks whether a preset flag, such as "IN_APP_THREAD_POOL," exists in a specific ThreadLocal variable of the current thread. If the flag does not exist, it means that the current thread has not yet executed the routing logic. At this time, the routing code performs the complete thread pool acquisition, task submission, and early return operations, and sets the flag in the current thread's ThreadLocal before returning. When the task is executed again in an independent thread pool, the routing code is called again. This time, it checks whether the "IN_APP_THREAD_POOL" flag already exists in the ThreadLocal, and determines that it is now in an independent thread pool. The routing code will directly skip the subsequent routing logic (i.e., it will not submit the task or return early). By using this judgment method based on ThreadLocal flags, it is ensured that the task can be processed normally in the independent thread pool, and the generation of infinite loops is effectively avoided.

[0097] This embodiment ensures that a request processing task is submitted only once, and that the submission target is the application's dedicated independent thread pool rather than the original shared thread pool, by terminating the execution flow of the original request processing method after submission to the independent thread pool. This blocking mechanism fundamentally avoids the possibility of double submission. If the task is only submitted to the independent thread pool without blocking the original path, Tomcat will still submit the same task to the shared thread pool, causing the same request to be processed by two thread pools, leading to resource waste, data races, and logical confusion. For example, the same HTTP request may be processed twice, resulting in duplicate responses or inconsistent data. Furthermore, by returning early, the routing code completely takes over the control of the request processing flow, making the entire thread pool redirection logic completely transparent to the upper-layer application. The upper-layer application is unaware of any changes in the request processing flow and still responds to requests in the original way, but the underlying thread resource allocation has been optimized to isolation mode. At the same time, by adding judgment logic when executing in the independent thread pool, circular calls are avoided, ensuring that the task can be executed correctly in the independent thread pool.

[0098] In some preferred embodiments, the method further includes: when submitting the HTTP request processing task to the independent thread pool, encapsulating the Web application identifier into a task object to be executed; when a worker thread in the independent thread pool executes the task object, obtaining the Web application identifier from the task object and binding the Web application identifier to the thread-local storage of the worker thread; and after the task object is completed, removing the Web application identifier from the thread-local storage of the worker thread.

[0099] In its implementation, the method further includes the following steps to maintain the propagation of the web application identifier when tasks are executed across threads. When submitting an HTTP request processing task to a separate thread pool, the web application identifier is encapsulated within the task object to be executed. Internally, the processing task is typically represented by a Runnable object, such as a SocketProcessor instance, which contains all the context information needed to process the request, including the socket, request object, and response object. Before submitting this Runnable object to the separate thread pool, the routing code needs to wrap or enhance it to attach the web application identifier to the object.

[0100] One implementation involves creating a new wrapper Runnable that holds a reference to the original Runnable object and also a web application identifier. The `run` method of the wrapper Runnable first binds the web application identifier to the current thread's thread-local storage, then calls the original Runnable's `run` method, and finally cleans up the thread-local storage after the call. The routing code submits the wrapper Runnable to a separate thread pool instead of directly submitting the original Runnable. When a worker thread in the separate thread pool executes the wrapper Runnable, its `run` method is executed. The wrapper Runnable first retrieves the pre-stored web application identifier from its own fields, and then associates this identifier with the current worker thread using the `set` method of `ThreadLocal`. This way, during the execution of the original Runnable's `run` method in the current worker thread, any subsequent code calls can retrieve the web application identifier using the `get` method of `ThreadLocal`. Furthermore, during the execution of the original Runnable, Servlets, filters, listeners, and business logic might be called. These can all utilize this mechanism to obtain the application identifier of the current request for purposes such as logging, monitoring tagging, or dynamic routing. Furthermore, after the original Runnable's `run` method completes execution, the wrapper Runnable's `run` method enters the `finally` block, calling the `ThreadLocal`'s `remove` method to remove the web application identifier stored in the current worker thread. This step is crucial because worker threads in the independent thread pool are reused; a thread is returned to the thread pool after processing a request to handle the next request. If the identifier stored in `ThreadLocal` is not cleaned up promptly, when the thread is assigned to a request from a different web application, it will still carry the identifier from the previous request, leading to contextual errors, incorrect logging, and even business logic exceptions.

[0101] This embodiment achieves correct transmission of application context information in a multi-threaded environment by encapsulating the web application identifier into a task object and binding it to the thread-local storage of the worker thread during task execution. Worker threads in an independent thread pool are reused resources; the same thread may execute tasks belonging to different web applications at different times. Without a context transmission mechanism, subsequent business code will be unable to perceive the application to which the current task belongs, leading to log confusion, inaccurate monitoring data, or routing errors. For example, if the logging system cannot distinguish which application's request is being processed, it will be difficult to locate the specific application when a problem occurs. This invention ensures that each task can accurately access the context information of its respective application throughout its entire lifecycle by binding the identifier to thread-local storage. Business code only needs to obtain the identifier from ThreadLocal without needing to care how the identifier is transmitted, achieving separation of concerns. The identifier is cleaned up immediately after task execution, avoiding context pollution problems caused by thread reuse. This mechanism provides fundamental support for building an application-level logging, monitoring, and diagnostic system, enabling operations personnel to aggregate and analyze system operation data by application dimension, improving system observability and maintainability.

[0102] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0103] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0104] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to execute a Tomcat container application thread pool isolation method based on a Java Agent.

[0105] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0106] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a Tomcat container application thread pool isolation method based on Java Agent.

[0107] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0108] The processor 502 is used to run a computer program 5032 stored in the memory to implement the steps of the Tomcat container application thread pool isolation method based on Java Agent provided in any of the above method embodiments.

[0109] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0110] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0111] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of a Tomcat container application thread pool isolation method based on a Java Agent implemented in any of the above method embodiments.

[0112] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0113] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0114] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0115] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0116] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0117] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0118] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0119] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A thread pool isolation method for Tomcat container applications based on Java Agent implementation, characterized in that, include: When the Tomcat container starts, the agent program is loaded through the Java Agent mechanism, and the agent program initializes a global application thread pool manager; The proxy program performs bytecode conversion on the network request processing class of the Tomcat container and inserts routing code into the request processing method of the network request processing class. The application thread pool manager creates a corresponding independent thread pool for each web application deployed in the Tomcat container; When an HTTP request is received, the web application identifier to which the HTTP request belongs is obtained through the routing code; Obtain the corresponding independent thread pool from the application thread pool manager based on the web application identifier; The HTTP request processing task is submitted to the obtained independent thread pool for execution, and the routing code prevents the processing task from being submitted to the Tomcat container's original shared thread pool; wherein, when the processing task is executed in the independent thread pool, the original processing flow of the processing task is directly executed.

2. The Tomcat container application thread pool isolation method based on Java Agent as described in claim 1, characterized in that, The step of creating a corresponding independent thread pool for each web application deployed in the Tomcat container through the application thread pool manager includes: Parse the external configuration file and read the thread pool parameters corresponding to each Web application identifier from the external configuration file; The application thread pool manager creates a corresponding independent thread pool for each web application based on the thread pool parameters.

3. The Tomcat container application thread pool isolation method based on Java Agent as described in claim 1, characterized in that, The step of performing bytecode conversion on the Tomcat container's network request handling class through the proxy program, and inserting routing code into the request handling method of the network request handling class, includes: Identify the endpoint handling class responsible for handling network sockets in the connector component of the Tomcat container; Insert the routing code at the entry point of the execution method of the internal task class of the endpoint processing class.

4. The Tomcat container application thread pool isolation method based on Java Agent implementation according to claim 2, characterized in that, The step of creating a corresponding independent thread pool for each web application through the application thread pool manager according to the thread pool parameters includes: When an HTTP request for any web application is received for the first time, the application thread pool manager creates an independent thread pool instance based on the Java concurrency package thread pool implementation according to the thread pool parameters corresponding to the web application identifier. The created independent thread pool instance is associated with the web application identifier and stored in the mapping relationship of the application thread pool manager, so as to serve as the independent thread pool corresponding to the web application.

5. The Tomcat container application thread pool isolation method based on Java Agent implementation according to claim 4, characterized in that, The step of obtaining the corresponding independent thread pool from the application thread pool manager based on the Web application identifier includes: Using the Web application identifier as the key, a search is performed in the mapping relationship of the application thread pool manager to obtain an independent thread pool instance stored in association with the Web application identifier.

6. The Tomcat container application thread pool isolation method based on Java Agent implementation according to claim 1, characterized in that, The step of obtaining the web application identifier to which the HTTP request belongs through the routing code includes: The context path is parsed from the internal request object corresponding to the HTTP request by inserting the routing code, and the context path is used as the identifier of the web application.

7. The Tomcat container application thread pool isolation method based on Java Agent implementation according to claim 1, characterized in that, Preventing the processing task from executing in the Tomcat container's original shared thread pool includes: After the processing task is submitted to the obtained independent thread pool, the execution flow of the request processing method is terminated by the routing code to skip the remaining logic in the request processing method used to submit the processing task to the Tomcat original shared thread pool.

8. The Tomcat container application thread pool isolation method based on Java Agent implementation according to claim 1, characterized in that, Also includes: When submitting the HTTP request processing task to the independent thread pool, the Web application identifier is encapsulated into the task object to be executed; When a worker thread in the independent thread pool executes the task object, it retrieves the Web application identifier from the task object and binds the Web application identifier to the thread-local storage of the worker thread. After the task object has been executed, the Web application identifier is removed from the thread-local storage of the worker thread.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images