An application debugging method, device, equipment and medium

Abstract

The present application provides an application debugging method, which is applied to an application debugging system. The application debugging system is used for code debugging of sub-application modules of an application. The application debugging system includes an interaction subsystem and a routing subsystem. The method includes: the interaction subsystem receives the identifiers of multiple sub-application modules input or selected by a user, then creates debugging sessions corresponding one by one to the multiple sub-application modules, and then generates multiple debugging request messages according to the multiple debugging sessions. Each debugging request message is routed by the routing subsystem to the proxy of the sub-application module to be debugged, so as to request to debug the code block of the corresponding sub-application module. Thus, debugging of multiple sub-application modules can be achieved simultaneously, improving the debugging efficiency.

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202010456122.7 and the application title "An Application Debugging Method, Device, Equipment and Medium", which was filed with the China National Intellectual Property Administration on May 26, 2020. The entire content of which is incorporated herein by reference. Technical Field

[0002] This application relates to the field of application development technologies, and in particular, to an application debugging method, device, equipment, and computer-readable storage medium. Background Art

[0003] An application is a collection of computer programs written for a specific application purpose of users. From project establishment to delivery to customers, an application usually goes through multiple stages such as development, testing, and going live. Among them, corresponding environments are often configured in each stage of development, testing, and going live, such as a development environment, a testing environment, and a production environment.

[0004] Developers often need to debug an application. The debugging of an application includes detecting errors in the program code of the application by manual or compilation means, and then the program code can be corrected according to the errors found during the debugging process.

[0005] The debugging efficiency of existing debugging methods is generally low and it is difficult to meet business requirements. How to efficiently debug an application has become a key issue of concern in the industry. Summary of the Invention

[0006] This application provides an application debugging method. This method supports debugging multiple sub-application modules of an application simultaneously, improving the debugging efficiency. This application also provides a method for processing a debugging request message, as well as a corresponding device, equipment, computer-readable storage medium, and computer program product for the above method.

[0007] In a first aspect, this application provides an application debugging method. This method can be executed by an application debugging system. The application debugging system is used to perform code debugging on sub-application modules of an application. An application usually includes multiple sub-application modules. A sub-application module refers to a functional module that realizes one or more functions through computer-executable code blocks, and the sub-application module can be one or more source code files. The sub-application module can run in a production environment to provide services. In some embodiments, the sub-application module can also be one or more microservices. The microservices run in a production environment to provide corresponding services.

[0008] The application debugging system includes a routing subsystem and at least one interaction subsystem. The application debugging system can support one or more users to perform code debugging on sub-application modules of an application through their respective interaction subsystems. For ease of description, the embodiments of this application use the process of one user performing code debugging on an application through one of the at least one interaction subsystems as an example for illustration.

[0009] Specifically, the interaction subsystem receives the identifiers of multiple sub-application modules input or selected by the user. Each sub-application module includes code blocks for implementing the functions of the application. Then, the interaction subsystem creates multiple debugging sessions, and these multiple debugging sessions correspond one-to-one to the multiple sub-application modules for which debugging is requested. Next, the interaction subsystem generates multiple debugging request messages based on the debugging session identifiers corresponding to the multiple debugging sessions. These multiple debugging request messages are routed by the routing subsystem to the agent of the sub-application module for which debugging is requested, for requesting to debug the code blocks of the corresponding sub-application module.

[0010] Among them, a debug session is specifically a session for debugging a sub-application module. The debug session corresponds one-to-one to the sub-application module to be debugged. Each debug session has a unique debug session identifier (debug session ID). By carrying the debug session identifier in the debugging request message, the debugging request message can be associated with both ends of the debug session, such as the sub-application module and the interaction subsystem. In this way, each debugging request message and the debugging response message for this debugging request message can be transmitted between the two ends of the debug session, and will not be transmitted to other sub-application modules or interaction subsystems. Thus, debugging multiple sub-application modules simultaneously is achieved, improving the debugging efficiency.

[0011] The agent corresponding to each sub-application module is a code block deployed in the production environment simultaneously with the application. This code block is used to proxy the interaction between the sub-application module and the outside world during runtime, as well as to debug the sub-application module. Among them, a sub-application module (such as a microservice) generates a process during runtime, and the agent of the sub-application module is substantially equivalent to an independent thread hosted in this process during runtime. The routing subsystem routes the debugging request messages generated by the user for debugging different sub-application modules to the agents of the corresponding sub-application modules respectively, and the agent starts debugging the sub-application module according to the debugging request message. When the application debugging system debugs the sub-application modules of the application, it does not block the above process and directly interacts through the threads hosted in the above process. In this way, it is possible to directly debug the sub-application modules of the application in the production environment, further improving the debugging efficiency.

[0012] In some possible implementations, the interaction subsystem generates a plurality of original debug request messages according to the identifiers of a plurality of sub-application modules, and then the interaction subsystem adds the debug session identifier corresponding to the sub-application module requesting debugging to the plurality of original debug request messages to obtain a plurality of debug request messages. Thereby, it can be realized that the plurality of debug request messages are respectively routed to the agents of the sub-application modules requesting debugging, so that each agent can start debugging the corresponding sub-application module according to the debug request message, improving the debugging efficiency.

[0013] In some possible implementations, the interaction subsystem can also create a global debug session. The two ends of the global debug session are the interaction subsystem and the application to be debugged (such as multiple sub-application modules of the application). The difference between the global debug session and the debug session corresponding to the sub-application module is that one global debug session corresponds to multiple sub-application modules requested to be debugged by one debug start operation, while one debug session corresponds to one sub-application module requested to be debugged. Therefore, one global debug session usually corresponds to multiple debug sessions. This global debug session can be used to manage the debug messages of multiple sub-application modules requested to be debugged by one debug start operation, such as filtering and aggregating multiple debug response messages.

[0014] The global debug session has a unique identifier, which is called the global debug session identifier. Based on this, the interaction subsystem can add the debug session identifier corresponding to the sub-application module requesting debugging and the global debug session identifier to the plurality of original debug request messages to generate a plurality of debug request messages.

[0015] Since the plurality of debug request messages also carry the global debug session identifier, therefore, the agent of the sub-application module can also carry the above global debug session identifier in the debug response message. In this way, when the interaction subsystem receives the debug response message, it can also filter and aggregate the plurality of debug response messages according to the global debug session identifier, specifically, filter and aggregate the debug response messages corresponding to different debug start operations. The interaction subsystem can generate a topology graph and / or a debug request response flow graph of the sub-application module according to the filtered and aggregated results, and present the above topology graph and / or request response flow graph to the user so that the user can view the debugging progress.

[0016] In some possible implementations, the interaction subsystem can also receive a plurality of debug response messages, and the plurality of debug response messages correspond one-to-one to the plurality of debug request messages sent by the interaction subsystem. Based on the plurality of debug response messages, it can be realized to debug a plurality of sub-application modules, improving the debugging efficiency.

[0017] In some possible implementations, the interaction subsystem may also establish a long connection with the routing subsystem before sending the multiple debug request messages to the routing subsystem. Through this long connection, the debug request messages can be transmitted multiple times, avoiding resource waste caused by establishing connections multiple times.

[0018] In some possible implementations, when the long connection fails to be established, the interaction subsystem may also discard the received debug request messages, such as the received original debug request messages. Specifically, the debug request messages (such as the original debug request messages) obtained by the interaction subsystem when establishing a long connection with the routing subsystem can be stored in a dedicated queue, such as a debug request queue. When the long connection is successfully established, the interaction subsystem creates a debug session for the sub-application module that requests debugging for the original debug request message. When the long connection fails to be established, the interaction subsystem can discard the received original debug request messages in the queue and reject creating the corresponding debug session. This avoids unnecessary resource waste and reduces resource overhead.

[0019] In some possible implementations, when there is no debug session at present, for example, when multiple debug sessions created by the interaction subsystem are closed, the interaction subsystem may disconnect the long connection with the routing subsystem. This avoids idling of network resources and improves resource utilization.

[0020] In a second aspect, the present application provides a method for processing debug request messages. This method can be executed by a debug adapter in the interaction subsystem. The debug adapter is essentially a piece of program code. This program code can be provided to the user in the form of a plugin, and the user can install the above plugin in an interaction module in the interaction subsystem, such as an integrated development environment (IDE). When the plugin is executed, a service process independent of the IDE and the programming language framework is generated. This service process of the debug adapter serves as an intermediate layer between the IDE and the routing subsystem, and is used to listen for debug start operations from the IDE and establish a long connection with the routing subsystem, such as a websocket connection. This long connection can be used to transmit debug messages, such as debug request messages.

[0021] Specifically, the debug adapter receives multiple original debug request messages, each original debug request message is used to request a sub-application module for debugging an application, and each sub-application module includes code blocks for implementing the functions of the application. Then, the debug adapter creates multiple debug sessions, and the multiple debug sessions correspond one-to-one to the multiple sub-application modules that request debugging. Next, the debug adapter generates multiple debug request messages based on the debug session identifiers corresponding to the multiple debug sessions and the multiple original debug request messages, and sends the multiple debug request messages.

[0022] Through this method, it is possible to simultaneously debug multiple sub-application modules of an application, improving the debugging efficiency and meeting the business requirements.

[0023] In some possible implementation manners, the debugging adapter can obtain multiple debugging request messages by adding the debugging session identifier corresponding to the sub-application module to be debugged to multiple original debugging request messages. Thus, it is possible to route the multiple debugging request messages to the agents of the sub-application modules to be debugged respectively, so that each agent can start debugging the corresponding sub-application module according to the debugging request message, improving the debugging efficiency.

[0024] In some possible implementation manners, the debugging adapter can also create a global debugging session. This global debugging session corresponds to the multiple debugging sessions. Correspondingly, the debugging adapter can add the debugging session identifier corresponding to the sub-application module to be debugged and the global debugging session identifier to the multiple original debugging request messages to obtain multiple debugging request messages. When the agent of the sub-application module receives the debugging request message, it starts code debugging of the corresponding sub-application module and generates a debugging response message. The global debugging session identifier is carried in the debugging response message. The global debugging session identifier can be used to filter and converge multiple debugging response messages, and then generate a topology graph and / or a debugging request response flow graph of the sub-application module for the user to view the debugging progress.

[0025] In some possible implementation manners, the debugging adapter can delete the standard message headers of the multiple original debugging request messages and add updated message headers to the multiple original debugging request messages. Among them, the updated message header includes the debugging session identifier corresponding to the sub-application module to be debugged. In this way, on the one hand, it can ensure that the debugging request message can be accurately routed to the agent of the corresponding sub-application module, and on the other hand, it can avoid increasing additional transmission overhead.

[0026] In some possible implementation manners, the debugging adapter can also receive multiple debugging response messages. These multiple debugging response messages correspond one by one to the multiple debugging request messages. Based on these multiple debugging response messages, it is possible to implement debugging of multiple sub-application modules, improving the debugging efficiency.

[0027] In some possible implementation manners, the debugging adapter can also delete the message headers of the multiple debugging response messages. Among them, the message headers of the multiple debugging response messages include the debugging session identifier. And the debugging adapter adds standard message headers to the multiple debugging response messages. In this way, on the one hand, it can ensure that the debugging response message can be recognized by an interaction module such as an IDE, and on the other hand, it can avoid increasing additional transmission overhead.

[0028] In some possible implementations, before sending the multiple debug request messages, the debug adapter may also establish a long connection with the routing subsystem. The routing subsystem is used to route the debug request messages to the proxy of the sub-application module that requests debugging. Through the above long connection, the debug request messages can be transmitted multiple times, avoiding resource waste caused by establishing connections multiple times.

[0029] In some possible implementations, when the establishment of the long connection fails, the debug adapter may also discard the received debug request messages. For example, discard the debug request messages in the debug request queue. This avoids unnecessary resource waste and reduces resource overhead.

[0030] In some possible implementations, when there is no debug session currently, for example, when the multiple debug sessions created by the debug adapter are closed, the debug adapter may disconnect the long connection with the routing subsystem. This avoids the idle of network resources and improves resource utilization.

[0031] In a third aspect, the present application provides an interaction subsystem. The application debugging system is used to perform code debugging on the sub-application modules of an application. The application debugging system includes a routing subsystem and an interaction subsystem. The interaction subsystem includes:

[0032] A communication unit, configured to receive the identifiers of multiple sub-application modules input or selected by a user. Each sub-application module includes code blocks for implementing the functions of the application.

[0033] A creation unit, configured to create multiple debug sessions, and the multiple debug sessions correspond to the multiple sub-application modules one by one.

[0034] A generation unit, configured to generate multiple debug request messages according to the multiple debug sessions. Each debug request message is routed by the routing subsystem to the proxy of the sub-application module that requests debugging, for requesting to debug the code blocks of the corresponding sub-application module.

[0035] In some possible implementations, each debug session includes a debug session identifier. The generation unit is specifically configured to:

[0036] Generate multiple original debug request messages according to the identifiers of the multiple sub-application modules.

[0037] Add the debug session identifier corresponding to the sub-application module that requests debugging to the multiple original debug request messages to obtain multiple debug request messages.

[0038] In some possible implementations, the creation unit is further configured to:

[0039] Create a global debug session, and the global debug session corresponds to the multiple debug sessions.

[0040] The generating unit is specifically configured to:

[0041] Add the debug session identifier corresponding to the sub-application module requesting debugging and the global debug session identifier to the multiple original debug request messages to generate multiple debug request messages.

[0042] In some possible implementation manners, the communication unit is further configured to:

[0043] Receive multiple debug response messages, where the multiple debug response messages correspond one-to-one to the multiple debug request messages.

[0044] In some possible implementation manners, the subsystem further includes:

[0045] A processing unit, configured to establish a long connection with the routing subsystem before sending the multiple debug request messages to the routing subsystem.

[0046] In some possible implementation manners, the processing unit is further configured to:

[0047] When the establishment of the long connection fails, discard the received debug request messages.

[0048] In some possible implementation manners, the subsystem further includes:

[0049] A processing unit, configured to disconnect the long connection with the routing subsystem when the multiple debug sessions are closed.

[0050] In a fourth aspect, the present application provides a processing device for debug request messages. The device includes:

[0051] A communication unit, configured to receive multiple original debug request messages, where each original debug request message is used to request debugging of a sub-application module of an application, and the code blocks included in each sub-application module are used to implement the functions of the application;

[0052] A creating unit, configured to create multiple debug sessions, where the multiple debug sessions correspond one-to-one to the multiple sub-application modules requesting debugging;

[0053] A generating unit, configured to generate multiple debug request messages according to the debug session identifiers corresponding to the multiple debug sessions and the multiple original debug request messages;

[0054] The communication unit is further configured to send the multiple debug request messages.

[0055] In some possible implementation manners, the generating unit is specifically configured to:

[0056] Add the debug session identifier corresponding to the sub-application module requesting debugging to the multiple original debug request messages to obtain multiple debug request messages.

[0057] In some possible implementation manners, the creating unit is further configured to:

[0058] Create a global debug session, where the global debug session corresponds to the multiple debug sessions;

[0059] The generating unit is specifically configured to:

[0060] Add the debug session identifier corresponding to the sub-application module requesting debugging and the global debug session identifier to the multiple original debug request messages to obtain multiple debug request messages.

[0061] In some possible implementation manners, the generating unit is specifically configured to:

[0062] Delete the standard message headers of the multiple original debug request messages;

[0063] Add updated message headers to the multiple original debug request messages, where the updated message headers include the debug session identifier corresponding to the sub-application module requesting debugging.

[0064] In some possible implementation manners, the communication unit is further configured to:

[0065] Receive multiple debug response messages, where the multiple debug response messages correspond one-to-one to the multiple debug request messages.

[0066] In some possible implementation manners, the generating unit is specifically configured to:

[0067] Delete the message headers of the multiple debug response messages, where the message headers of the debug response messages include the debug session identifier;

[0068] Add standard message headers to the multiple debug response messages.

[0069] In some possible implementation manners, the device further includes:

[0070] A processing unit, configured to establish a long connection with a routing subsystem, where the routing subsystem is used to route the debug request message to the proxy of the sub-application module requesting debugging.

[0071] In some possible implementation manners, the processing unit is further configured to:

[0072] When the establishment of the long connection fails, discard the received debug request messages.

[0073] In some possible implementation manners, the device further includes:

[0074] A processing unit, configured to disconnect from the routing subsystem when the multiple debug sessions are closed.

[0075] In a fifth aspect, the present application provides a device, which includes a processor and a memory. The processor and the memory communicate with each other. The processor is configured to execute instructions stored in the memory, so that the device executes the method in any implementation manner of the first aspect or the second aspect.

[0076] In a sixth aspect, the present application provides a computer-readable storage medium, in which instructions are stored, and the instructions direct a device to execute the method in any implementation manner of the first aspect or the second aspect described above.

[0077] In a seventh aspect, the present application provides a computer program product including instructions, which, when running on a device, cause the device to execute the method in any implementation manner of the first aspect or the second aspect described above.

[0078] Based on the implementation manners provided in the above aspects, the present application can be further combined to provide more implementation manners. BRIEF DESCRIPTION OF THE DRAWINGS

[0079] To more clearly illustrate the technical solutions in the embodiments of the present application, the accompanying drawings required for the embodiments will be briefly introduced below.

[0080] Figure 1 A scenario diagram of an application debugging method provided by an embodiment of the present application;

[0081] Figure 2A A system architecture diagram of an application debugging system provided by an embodiment of the present application;

[0082] Figure 2B A system architecture diagram of an application debugging system provided by an embodiment of the present application;

[0083] Figure 2C A system architecture diagram of an application debugging system provided by an embodiment of the present application;

[0084] Figure 3 A flowchart of an application debugging method provided by an embodiment of the present application;

[0085] Figure 4 A schematic diagram of message processing provided by an embodiment of the present application;

[0086] Figure 5 A schematic structural diagram of an interaction subsystem provided by an embodiment of the present application;

[0087] Figure 6Schematic structural diagram of a processing device for a debugging request message provided by an embodiment of the present application;

[0088] Figure 7 Schematic structural diagram of a device provided by an embodiment of the present application. Detailed implementation manners

[0089] In the embodiments of the present application, the terms "first" and "second" are only used for descriptive purposes, and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features.

[0090] First, some technical terms involved in the embodiments of the present application are introduced.

[0091] An application (APP) is a collection of computer programs written for a specific application purpose of users. Specifically, it can be a single application program or an application software formed by a collection of multiple application programs. For example, in the office field, the application can be a single text editing application, or an application composed of a text editing application, a table editing application, and a graphic editing application.

[0092] An application usually includes multiple sub-application modules. A sub-application module is a functional module that realizes one or more functions through computer-executable code blocks. The sub-application module can be one or more source code files. The sub-application module can run in a production environment to provide services. Among them, the production environment refers to the environment for officially providing services. The production environment includes at least one node, and the node refers to a computing node with computing capabilities such as a server and a terminal computing device.

[0093] For complex applications with numerous functions, developers can adopt a microservices architecture (MSA) for development to improve development efficiency. Among them, the microservices architecture means splitting the functional modules of an application into independent microservices. A microservice is a collection of one or a group of relatively small and independent functional units. Microservices achieve data interaction through interface calls. In this way, decoupling of each functional module of the application can be achieved. When the application needs to add, delete, or modify functions, developers only need to add, delete, or modify the corresponding microservices. The sub-application module can also be one or more microservices. The microservices run in a production environment to provide corresponding services.

[0094] Considering that different programming languages (technology stacks) have their own advantages, developers can develop sub-application modules of an application in different programming languages according to requirements when developing an application. For example, developers can develop some sub-application modules of an application in C language and develop other sub-application modules of the application in Python language.

[0095] When developers use development tools such as an editor or an integrated development environment (IDE) to debug sub-application modules of an application, in order to debug sub-application modules in different programming languages, separate extensions or debugging modules need to be written for development tools such as the editor to call the corresponding debugger. This increases the development difficulty and cost of the editor, and the editor itself also becomes relatively large, with high hardware requirements, affecting the user experience.

[0096] Based on this, the industry has proposed a debug adapter protocol (DAP). Each editor can communicate with debuggers in different programming languages through the same protocol, i.e., DAP, without writing extensions or debugging modules for different programming languages for the editor, reducing the development difficulty and cost of the editor, and a lightweight editor can be implemented, improving the usability and user experience of the editor.

[0097] Considering that some debuggers do not support DAP, a debug adapter can also be configured for the debugger. Development tools such as an editor and an IDE can communicate with the debug adapter corresponding to the debugger to implement debugging of sub-application modules in the corresponding programming language. However, the debugging method based on DAP usually only supports debugging one sub-application module of an application at a time, with low debugging efficiency. How to efficiently debug an application has become a key issue of concern in the industry.

[0098] In view of this, an embodiment of the present application provides an application debugging method. This method can be executed by an application debugging system. The application debugging system is used to perform code debugging on sub-application modules of an application. The application debugging system includes a routing subsystem and at least one interaction subsystem. The application debugging system in the embodiment of the present application can support one or more users to perform code debugging on sub-application modules of an application through their respective interaction subsystems.

[0099] For ease of description, an example of the process of a user debugging the code of an application through one of at least one interaction subsystem is used in the embodiments of this application. Specifically, the interaction subsystem receives the identifiers of multiple sub-application modules input or selected by the user. Each sub-application module includes code blocks for implementing the functions of the application. Then, the interaction subsystem creates multiple debugging sessions, and these multiple debugging sessions correspond one-to-one to the multiple sub-application modules for which debugging is requested. Next, the interaction subsystem generates multiple debugging request messages according to the debugging session identifiers corresponding to the multiple debugging sessions. These multiple debugging request messages are routed by the routing subsystem to the agent of the sub-application module for which debugging is requested, for requesting to debug the code blocks of the corresponding sub-application module.

[0100] Among them, a debugging session is specifically a session for debugging a sub-application module. The debugging sessions correspond one-to-one to the sub-application modules to be debugged. Each debugging session has a unique debugging session identifier (debug session ID). By carrying the debugging session identifier in the debugging request message, the debugging request message can be associated with both ends of the debugging session, such as the sub-application module and the interaction subsystem. In this way, each debugging request message and the debugging response message for this debugging request message can be transmitted between the two ends of the debugging session, and will not be transmitted to other sub-application modules or interaction subsystems. Thus, debugging multiple sub-application modules simultaneously is achieved, improving the debugging efficiency.

[0101] The agent corresponding to each sub-application module is a code block deployed in the production environment simultaneously with the application. This code block is used to proxy the interaction between the sub-application module and the outside world during operation, as well as to debug the sub-application module. Among them, a sub-application module (such as a microservice) generates a process during operation. The agent of the sub-application module is essentially equivalent to an independent thread hosted in this process during operation. The routing subsystem routes the debugging request messages generated by the user for debugging different sub-application modules to the agents of the corresponding sub-application modules respectively. The agent starts debugging the sub-application module according to the debugging request message. When the application debugging system debugs the sub-application module of the application, it does not block the above process and directly interacts through the thread hosted in the above process. In this way, it is possible to directly debug the sub-application module of the application in the production environment, improving the debugging efficiency.

[0102] To make the technical solution of this application clearer and easier to understand, the application scenarios of the application debugging method provided in the embodiments of this application are introduced below with reference to the accompanying drawings.

[0103] Such as Figure 1As shown, the application debugging system 100 has established a communication path with the data center 300. The application debugging system 100 is used to debug at least one application 200 deployed on the data center 300. Among them, the data center 300 provides a production environment, and the application 200 is deployed in the production environment. The application 200 includes multiple sub-application modules, and the code blocks included in each sub-application module are used to implement the functions of the application 200.

[0104] The sub-application modules of the application 200 can be distributedly deployed on at least one node of the data center 300. For example, in Figure 1 the example, n sub-application modules of the application 200 are distributedly deployed on k nodes (also called hosts) of the data center, where k is less than or equal to n. It should be noted that the sub-application modules can be directly deployed on the nodes, that is, deployed in the physical machines, or can be deployed in the virtual machines or containers on the nodes. When each sub-application module of the application 200 is deployed in an independent container, the sub-application modules running in the container can interact through the interfaces of the container.

[0105] Each sub-application module has an agent (when the sub-application module is a microservice, it is also called a microservice agent). This agent can be created by means of code injection. Code injection is a technique of inserting independently running code into a target process and making it run. Code injection can generally be implemented by configuring environment variables. Taking the Java platform as an example, the environment variable can be JAVA_TOOL_OPTIONS. By assigning the environment variable to the name of the code file to be inserted, for example, export JAVA_TOOL_OPTIONS = "-agent-lib:hprof", when the process of the sub-application module (such as a microservice) starts, the code in the inserted code file is written into the virtual memory space of the above process, and the thread corresponding to the inserted code also starts with the start of the process. Before the host process terminates, the thread can keep running.

[0106] The application debugging system 100 includes a routing subsystem 104 and at least one interaction subsystem 102. The application debugging process will be described below from the perspective of one interaction subsystem 102. The interaction subsystem 102 can receive the identifiers of multiple sub-application modules input or selected by the user. Then, the interaction subsystem 102 creates multiple debugging sessions, where the multiple debugging sessions correspond one-to-one to the multiple sub-application modules. Next, the interaction subsystem 102 generates multiple debugging request messages based on the debugging session identifiers corresponding to the multiple debugging sessions. Then, the interaction subsystem 102 sends the multiple debugging request messages to the routing subsystem 104, and the routing subsystem 104 can route the multiple debugging request messages to the agents of the sub-application modules that request debugging respectively. The agent can initiate code debugging of the corresponding sub-application module according to the debugging request message.

[0107] In some possible implementation manners, each node where a sub-application module is located has a node agent. This node agent is also called a host agent. The host agent is a code block deployed in the production environment simultaneously with the application 200. The host agent is used to forward messages from the sub-application modules on the node or forward messages to the sub-application modules on the node. When the host agent runs, it can generate a process. The program code corresponding to this process can be deployed to the node when the code block included in the sub-application module of the application 200 is deployed to the node. When the process of the sub-application module on the node starts, the host agent also starts accordingly.

[0108] Based on this, when the routing subsystem 104 routes the debugging request messages, it can first transmit the multiple debugging request messages to the host agent of the node where the sub-application module that requests debugging is located, and then transmit the multiple debugging request messages to the agent corresponding to the sub-application module that requests debugging through the host agent.

[0109] In some possible implementation manners, the interaction subsystem 102 can include an interaction module and a debug adapter. Among them, the interaction module is used to provide a user interface, such as a graphical user interface (GUI) or a command user interface (CUI) and other user interfaces. The user can perform debugging operations through the above user interfaces.

[0110] For example, the interaction module presents the sub - application modules of application 200 to the user through the GUI, and the user can perform debugging selection and debugging start operations through the GUI. Among them, the debugging selection includes selecting the sub - application module to be debugged. In some embodiments, the debugging selection may also include the debugging type, such as breakpoint debugging, step - by - step debugging, variable tracking, etc. Also, for example, the user can also directly send debugging selection and debugging start operations in the form of commands through the CUI.

[0111] The interaction module can be an integrated development environment (IDE) that provides application debugging functions. This IDE can not only be used to edit the program code of application 200 and debug the program code during the development process, but also debug the remotely deployed application 200. The interaction module can also be other interaction modules that can provide the function of debugging the deployed application 200, such as a browser loaded with a user interface for debugging application 200 or an interaction module dedicated to application debugging. For the convenience of description, the following takes the interaction module as the IDE for example.

[0112] The debug adapter is essentially a piece of program code. This program code can be provided to the user in the form of a plugin, and the user can install the above - mentioned plugin in the IDE. When this plugin is executed, a service process independent of the IDE and the programming language framework is generated. This service process of the debug adapter serves as an intermediate layer between the IDE and the routing subsystem, used to listen for debugging start operations from the IDE and establish a long - term connection with the routing subsystem, such as a websocket connection. This long - term connection can be used to transmit debugging messages, such as debugging request messages.

[0113] Figure 1 The shown application debugging system 100 has multiple deployment methods, and the deployment methods of the application debugging system 100 will be described in detail below.

[0114] In some implementation manners, each subsystem of the application debugging system 100 can be distributedly deployed in different environments. For example, as Figure 2A shown, the interaction subsystem 102 can be deployed in a terminal computing device (such as a desktop computer, a laptop computer, etc., user terminals), and the routing subsystem 104 can be deployed in a cloud computing cluster (including at least one cloud computing device, such as a cloud server, etc.).

[0115] In Figure 2AIn the scenario where the interaction module can be a local IDE. Herein, "local" also refers to a local device. The local device includes a terminal computing device (such as a desktop computer, a laptop, etc.) directly under the control of a user. The local IDE refers to an IDE installed in the local device in the form of a client. In some examples, the local IDE can include visualstudio, eclipse, etc. The debug adapter can be provided to the user in the form of a plugin, and the user can install the plugin in the local IDE to debug the application 200. Among them, the installation packages of the IDE and the debug adapter can be provided by the same manufacturer or different manufacturers.

[0116] In some other implementation manners, each subsystem of the application debugging system 100 can also be deployed in the same environment. For example, as Figure 2B shown, the interaction subsystem 102 and the routing subsystem 104 can be deployed in the same cloud computing cluster. The cloud computing cluster can be a public cloud provided by a cloud service provider. The interaction module can be a cloud IDE (cloud IDE). The routing subsystem 104 can form a cloud debugger for providing cloud debugging services.

[0117] The cloud service provider can integrate the cloud debugger and the cloud IDE into a cloud service for the user to use, or can separately provide two cloud services of the cloud IDE and the cloud debugger for the user to use. In some cases, the cloud service provider can regard the cloud debugger as a value-added service of the cloud IDE. After the user purchases or leases the value-added service, the cloud service provider combines it with the cloud IDE and provides it to the user.

[0118] Of course, as Figure 2C shown, the interaction subsystem 102 and the routing subsystem 104 can also be deployed in different cloud computing clusters. Different cloud computing clusters can be public clouds provided by different cloud service providers. Different cloud service providers separately provide the cloud IDE and the cloud debugger for the user to use.

[0119] Furthermore, the application 200 debugged by the application debugging system 100 can be deployed in the same or different cloud computing clusters as the interaction subsystem 102 and / or the routing subsystem 104, or can be independently deployed in any data center (such as a user-owned data center). The foregoing Figure 2A 、 Figure 2B 、 Figure 2C exemplarily shows the situation where the application 200 is deployed in the data center 300, which does not constitute a limitation on the technical solution of the present application.

[0120] In addition, Figure 2A , Figure 2B , Figure 2C only some specific examples of the application debugging system 100 being deployed in different environments or the same environment are shown exemplarily. In some implementation manners, each module of the application debugging system 100 can also be deployed in other environments. For example, the interaction module and the debug adapter can be deployed in a terminal computing device or a cloud computing device, and the routing subsystem 104 can be deployed in an edge computing cluster (including at least one edge computing device, such as an edge server).

[0121] To make the technical solution of the present application clearer and easier to understand, the application debugging method provided by the embodiments of the present application will be introduced in detail below from the perspective of an interaction subsystem 102 in conjunction with the accompanying drawings.

[0122] Refer to Figure 3 the flowchart of the application debugging method shown in, the method includes:

[0123] S302: The interaction subsystem 102 receives the identifiers of multiple sub-application modules input or selected by the user.

[0124] The interaction subsystem 102 (specifically, the interaction module) can present a list of sub-application modules of the application 200 and / or a topology graph of the sub-application modules of the application 200 to the user through a user interface. Among them, the topology graph of the sub-application modules is used to identify the call relationship between each sub-application module of the application 200. The user can select multiple sub-application modules through the above-mentioned user interface (such as a GUI), and the interaction subsystem 102 receives the identifiers of the multiple sub-application modules selected by the user through the user interface (such as a GUI).

[0125] In some possible implementation manners, the user can directly input the identifiers of multiple sub-application modules through the above-mentioned user interface (such as a CUI), and the interaction module of the interaction subsystem 102 receives the identifiers of the multiple sub-application modules input by the user through the user interface (such as a CUI) to debug the multiple sub-application modules.

[0126] Each sub-application module has a unique identifier. The identifiers of different sub-application modules are different. In some embodiments, the identifier of the sub-application module can be the name, number, etc. of the sub-application module. Taking the sub-application module as a microservice as an example, the identifier of the sub-application module can be the microservice name.

[0127] S304: The interaction subsystem 102 creates multiple debug sessions.

[0128] The debug adapter in the interaction subsystem 102 can listen for debug start operations. When the debug adapter listens for debug start operations for multiple sub-application modules, it can create multiple debug sessions corresponding one-to-one to the sub-application modules.

[0129] Specifically, when the user selects or inputs the identifiers of multiple sub-application modules through the interaction module of the interaction subsystem 102 and starts debugging the multiple sub-application modules, the interaction module can generate multiple original debug request messages. An original debug request message refers to a request message generated by the interaction module based on the native DAP protocol for debugging a sub-application module. Each original debug request message is used to request debugging of one sub-application module among the multiple sub-application modules. Different original debug request messages request debugging of different sub-application modules.

[0130] When the debug adapter listens for multiple original debug request messages, it can create multiple debug sessions. The multiple debug sessions correspond one-to-one to the multiple sub-application modules requested for debugging by the multiple original debug request messages. Among them, when the debug adapter in the interaction subsystem 102 creates a debug session, it can first detect whether a debug session corresponding to the sub-application module requested for debugging by the original debug request message exists. If not, it creates the corresponding debug session. If so, it can skip the step of creating the debug session.

[0131] In some possible implementation manners, the debug adapter in the interaction subsystem 102 can also maintain a debug request queue, which is specifically used to store the original debug request messages sent by an interaction module such as an IDE. The debug adapter can sequentially read the original debug request messages from the debug request queue to execute the step of creating the corresponding debug sessions.

[0132] Among them, a debug session is specifically a session for debugging a sub-application module. The debug session corresponds one-to-one to the sub-application module being debugged. Each debug session has a unique debug session identifier. By carrying the debug session identifier in the debug request message, the debug request message can be associated with both ends of the debug session, such as the sub-application module and the interaction subsystem. In this way, each debug request message and the debug response message for this debug request message can be transmitted between both ends of the debug session, and will not be transmitted to other sub-application modules or interaction subsystems.

[0133] Each debugging session has a unique identifier, which is called the debug session ID. Both ends of each debugging session correspond to an interaction subsystem (specifically, an interaction module such as an IDE) and a sub-application module (specifically, the agent of the sub-application module). Therefore, the debug adapter can generate the debug session ID based on the identifier of the interaction subsystem (such as the identifier of the user using the interaction subsystem, i.e., the user ID) and the identifier of the sub-application module (such as the identifier of the resource to which the sub-application module belongs, i.e., the resource ID).

[0134] In some examples, the debug adapter can splice the user ID of the interaction subsystem and the resource ID of the resource to which the sub-application module belongs to generate the debug session ID. Further, the debug adapter can also splice the user ID of the interaction subsystem, the resource ID of the resource to which the sub-application module belongs, and a reserved field to generate the debug session ID. Among them, the reserved field can be a fixed value or a random number generated randomly.

[0135] In some possible implementation manners, the debug adapter can also sort multiple debug sessions and use the serial number as the debug session ID, or the debug adapter can generate a random number as the debug session ID. When the debug adapter uses the serial number or the random number as the debug session ID, the debug adapter can also associate the debug session ID with the user ID of the corresponding interaction subsystem and the resource ID of the resource to which the sub-application module belongs. For example, the debug adapter can store the debug session ID and the corresponding user ID of the interaction subsystem and the resource ID of the resource to which the sub-application module belongs in the debug session object.

[0136] S306: The interaction subsystem 102 generates multiple debug request messages according to multiple debugging sessions.

[0137] The interaction subsystem 102 (specifically, the interaction module in the interaction subsystem 102) can generate multiple original debug request messages according to multiple sub-application module identifiers, and then the interaction module can send the multiple original debug request messages to the debug adapter. The interaction subsystem 102 (specifically, the debug adapter in the interaction subsystem 102) can add the debug session ID corresponding to the sub-application module requesting debugging to the multiple original debug request messages to obtain multiple debug request messages.

[0138] The interaction subsystem 102 (specifically, the debug adapter in the interaction subsystem 102) can send multiple debug request messages to the routing subsystem. The routing subsystem can route the multiple debug request messages to the proxies of the sub-application modules that request debugging respectively. The proxy of the sub-application module receives the debug request message and starts the code debugging of the sub-application module, such as breakpoint debugging, single-step execution, variable tracking, etc. of the code block of the sub-application module. The proxy of the sub-application module can also generate a debug response message. The debug session identifier can be carried in the debug response message so that the routing subsystem can route the debug response message to the corresponding interaction subsystem according to the debug session identifier.

[0139] In some possible implementation manners, the interaction subsystem 102 (specifically, the debug adapter in the interaction subsystem 102) can also create a global debug session for one debug start operation. Both ends of the global debug session are the interaction subsystem 102 and the application 200 to be debugged (such as multiple sub-application modules of the application 200). The difference between the global debug session and the debug session corresponding to the sub-application module is that one global debug session corresponds to multiple sub-application modules requested to be debugged by one debug start operation request, while one debug session corresponds to one sub-application module requested to be debugged. Therefore, one global debug session usually corresponds to multiple debug sessions. The global debug session can be used to manage the debug messages of multiple sub-application modules requested to be debugged by one debug start operation request, such as screening and aggregating multiple debug response messages.

[0140] The global debug session has a unique identifier, which is called the global debug session identifier. Based on this, the interaction subsystem 102 (specifically, the debug adapter in the interaction subsystem 102) can add the debug session identifier corresponding to the sub-application module requested to be debugged and the global debug session identifier to the multiple original debug request messages to generate multiple debug request messages.

[0141] Since the global debug session identifier is also carried in the multiple debug request messages, the proxy of the sub-application module can also carry the above global debug session identifier in the debug response message. In this way, when the interaction subsystem 102 receives the debug response message, it can also screen and aggregate the multiple debug response messages according to the global debug session identifier, specifically, screen and aggregate the debug response messages corresponding to different debug start operations. The interaction subsystem 102 can generate a topology graph of the sub-application module and / or a debug request response flow graph according to the screened and aggregated results, and present the above topology graph and / or request response flow graph to the user.

[0142] Considering that the native DAP protocol does not support resource identification or multiple debugging sessions, the original debug request message does not carry a resource identifier or a debug session identifier. The debug adapter can add metadata including the resource identifier and the debug session identifier to the original debug request message (which can also be called a DAP message) to generate a debug request message. Specifically, the debug adapter can add the above metadata to the message header of the original debug request message to obtain a debug request message.

[0143] In some possible implementation manners, the metadata may further include a global session identifier, that is, a global session ID. In this way, the interaction subsystem can also filter and aggregate the debug response messages returned by the proxy of the sub-application module according to the global session ID, thereby generating a request-response flow graph and displaying the request-response flow graph in the interaction subsystem.

[0144] Considering the transmission overhead, the interaction subsystem 102 (specifically, the debug adapter in the interaction subsystem 102) can also delete the standard message header of the original debug request message and add an updated message header to multiple original debug request messages. The updated message header includes the debug session identifier corresponding to the sub-application module for which debugging is requested, thereby obtaining a debug request message. Among them, the updated message header may also include at least one of the global session identifier and the resource identifier.

[0145] Furthermore, when the interaction subsystem 102 (specifically, the debug adapter in the interaction subsystem 102) receives multiple debug response messages, it can also delete the message headers of the multiple debug response messages. The message headers include the debug session identifier, and add a standard message header, such as a DAP message header, to the multiple debug response messages to obtain a processed debug response message. Then, the debug adapter returns the processed debug response message to an interaction module such as an IDE.

[0146] For ease of understanding, this application also provides an example to illustrate the process of processing the original debug request message to obtain a debug request message, and processing the debug response message to obtain a processed debug response message.

[0147] See Figure 4 , after receiving the original debug request message from the IDE, the debug adapter can delete the DAP header of the original debug request message, and then add metadata in the following format to form a debug request message:

[0148] struct TDapWrapper{

[0149] 1: string resource ID

[0150] 2: string global session ID

[0151] 3: string session ID

[0152] 4: string dapJsonString

[0153] }

[0154] Among them, the resource ID represents the resource identifier, the global session ID represents the global debug session identifier, the session ID represents the debug session identifier, and the dapJsonString represents the message content.

[0155] Such as Figure 4 shown, when the debug adapter receives the original debug request message from the IDE, it deletes the DAP header of the original debug request message. In this example, the DAP header of the original debug request message is:

[0156] Content-Length: 107\r\n\r\n.

[0157] Then, the debug adapter adds metadata to the original debug request message. Specifically, the debug adapter can add an updated message header to the original debug request message, and the updated message header carries metadata such as the resource ID, global session ID, and session ID, so as to obtain the debug request message.

[0158] When the debug adapter receives the debug response message from the agent of the sub-application module, it can delete the metadata in the debug response message, specifically delete the resource ID, global session ID, and session ID, retain the content in the dapJsonString, and then add a DAP message header, that is, Content-Length: 107\r\n\r\n, to obtain the processed debug response message. The debug adapter returns the processed debug response message to the IDE.

[0159] Based on the above description, an embodiment of the present application provides an application debugging method. The interaction subsystem 102 receives the identifiers of multiple sub-application modules input or selected by the user, and then the interaction subsystem 102 creates multiple debugging sessions, where these multiple debugging sessions correspond one-to-one to the multiple sub-application modules for which debugging is requested. Then, the interaction subsystem 102 generates multiple debugging request messages according to the debugging session identifiers corresponding to the multiple debugging sessions. These multiple debugging request messages are routed by the routing subsystem 104 to the proxy of the sub-application module for which debugging is requested, for requesting to debug the code blocks of the corresponding sub-application module.

[0160] The debugging session identifier is carried in the debugging request message, which can establish a connection between the debugging request message and both ends of the debugging session, such as the sub-application module and the interaction subsystem. In this way, each debugging request message and the debugging response message for this debugging request message can be transmitted between the two ends of the debugging session, rather than being transmitted to other sub-application modules or the interaction subsystem. Thus, debugging multiple sub-application modules simultaneously is achieved, improving the debugging efficiency.

[0161] In Figure 3 In the shown embodiment, the interaction subsystem 102 (specifically, the debug adapter in the interaction subsystem 102) can establish a long connection with the routing subsystem 104 before transmitting multiple debugging request messages. Further, to avoid resource waste, the debug adapter can disconnect the long connection between the debug adapter and the routing subsystem when there are no debugging sessions, for example, when all multiple debugging sessions are closed. When the debug adapter monitors a new debugging start operation and receives a new original debugging request message, it then establishes a long connection with the routing subsystem 104.

[0162] In some possible implementation manners, the debug adapter can add the received original debugging request message to the debugging request queue when establishing a connection. When the long connection between the debug adapter and the routing subsystem 104 is successfully established, the debug adapter creates corresponding debugging sessions for each original debugging request message in the debugging request queue. When the long connection between the debug adapter and the debugging proxy fails to be established, the debug adapter can discard all queued original debugging request messages. Further, the debug adapter can also return a prompt message to an interaction module such as an IDE to prompt that the connection establishment fails. In this way, the interaction module can re-establish a long connection with the debug adapter.

[0163] As described above in combination with Figures 1 to 4A detailed introduction to the application debugging method provided by the embodiments of the present application is given. Next, the devices and equipment provided by the embodiments of the present application will be introduced with reference to the accompanying drawings.

[0164] See Figure 5 The structural schematic diagram of the interaction subsystem 102 shown, the interaction subsystem 102 includes:

[0165] A communication unit 1022, configured to receive the identifiers of multiple sub-application modules input or selected by a user, where each sub-application module includes code blocks for implementing the functions of the application;

[0166] A creation unit 1024, configured to create multiple debugging sessions, where the multiple debugging sessions correspond to the multiple sub-application modules one by one;

[0167] A generation unit 1026, configured to generate multiple debugging request messages according to the multiple debugging sessions, and each debugging request message is routed by the routing subsystem to the proxy of the sub-application module requesting debugging, so as to request to debug the code blocks of the corresponding sub-application module.

[0168] Among them, the above-mentioned communication unit 1022, creation unit 1024, and generation unit 1026 may be software units, and these software units may be deployed in a terminal device or a cloud device. Of course, the above units may also be hardware units. The embodiments of the present application do not make any limitations in this regard.

[0169] In some possible implementation manners, each debugging session includes a debugging session identifier, and the generation unit 1026 is specifically configured to:

[0170] Generate multiple original debugging request messages according to the identifiers of multiple sub-application modules;

[0171] Add the debugging session identifier corresponding to the sub-application module requesting debugging to the multiple original debugging request messages to obtain multiple debugging request messages.

[0172] In some possible implementation manners, the creation unit 1024 is further configured to:

[0173] Create a global debugging session, where the global debugging session corresponds to the multiple debugging sessions;

[0174] The generation unit 1026 is specifically configured to:

[0175] Add the debugging session identifier corresponding to the sub-application module requesting debugging and the global debugging session identifier to the multiple original debugging request messages to generate multiple debugging request messages.

[0176] In some possible implementation manners, the communication unit 1022 is further configured to:

[0177] Receive a plurality of debug response messages, where the plurality of debug response messages correspond one-to-one to the plurality of debug request messages.

[0178] In some possible implementations, the subsystem 102 further includes:

[0179] A processing unit, configured to establish a long connection with the routing subsystem before sending the plurality of debug request messages to the routing subsystem.

[0180] In some possible implementations, the processing unit is further configured to:

[0181] When the establishment of the long connection fails, the interaction subsystem discards the received debug request messages.

[0182] In some possible implementations, the subsystem further includes:

[0183] A processing unit, configured to disconnect the long connection with the routing subsystem when the plurality of debug sessions are closed.

[0184] The interaction subsystem 102 according to an embodiment of the present application may correspondingly execute the methods described in the embodiments of the present application, and the above and other operations and / or functions of each module / unit of the interaction subsystem 102 are respectively for implementing Figure 3 The corresponding processes of the respective methods in the illustrated embodiments, and for the sake of brevity, will not be described in detail herein.

[0185] The present application also provides a processing device for debug request messages. The device may specifically be a debug adapter as Figure 1 shown. The structure of the device will be described in detail below with reference to the accompanying drawings.

[0186] See Figure 6 The structural schematic diagram of the processing device for debug request messages shown, the device 600 includes:

[0187] A communication unit 602, configured to receive a plurality of original debug request messages, each original debug request message being used to request a sub-application module of a debug application, and the code blocks included in each sub-application module being used to implement the functions of the application;

[0188] A creation unit 604, configured to create a plurality of debug sessions, where the plurality of debug sessions correspond one-to-one to the plurality of sub-application modules to be debugged;

[0189] A generation unit 606, configured to generate a plurality of debug request messages according to the debug session identifiers corresponding to the plurality of debug sessions and the plurality of original debug request messages;

[0190] The communication unit 602 is further configured to send the plurality of debug request messages.

[0191] In some possible implementations, the generating unit 606 is specifically configured to:

[0192] Add the debug session identifier corresponding to the sub-application module requesting debugging to the multiple original debug request messages to obtain multiple debug request messages.

[0193] In some possible implementations, the creating unit 604 is further configured to:

[0194] Create a global debug session, where the global debug session corresponds to the multiple debug sessions;

[0195] The generating unit 606 is specifically configured to:

[0196] Add the debug session identifier corresponding to the sub-application module requesting debugging and the global debug session identifier to the multiple original debug request messages to obtain multiple debug request messages.

[0197] In some possible implementations, the generating unit 606 is specifically configured to:

[0198] Delete the standard message headers of the multiple original debug request messages;

[0199] Add updated message headers to the multiple original debug request messages, where the updated message headers include the debug session identifier corresponding to the sub-application module requesting debugging.

[0200] In some possible implementations, the communication unit 602 is further configured to:

[0201] Receive multiple debug response messages, where the multiple debug response messages correspond one-to-one to the multiple debug request messages.

[0202] In some possible implementations, the generating unit 606 is specifically configured to:

[0203] Delete the message headers of the multiple debug response messages, where the message headers of the debug response messages include the debug session identifier;

[0204] Add standard message headers to the multiple debug response messages.

[0205] In some possible implementations, the apparatus 600 further includes:

[0206] A processing unit, configured to establish a long connection with a routing subsystem, where the routing subsystem is used to route the debug request message to the proxy of the sub-application module requesting debugging.

[0207] In some possible implementations, the processing unit is further configured to:

[0208] When the long connection establishment fails, discard the received debug request message.

[0209] In some possible implementations, the apparatus 600 further includes:

[0210] A processing unit, configured to disconnect the connection with the routing subsystem when the multiple debug sessions are closed.

[0211] The processing apparatus 600 for debug request messages according to the embodiments of the present application may correspond to executing the methods described in the embodiments of the present application, and the above and other operations and / or functions of each module / unit of the processing apparatus 600 for debug request messages are respectively for implementing Figure 3 the corresponding processes of the respective methods in the illustrated embodiments, and for the sake of brevity, will not be described herein again.

[0212] Embodiments of the present application further provide a computing device 700. The computing device 700 may be a terminal computing device such as a laptop computer or a desktop computer, or a cloud computing device in a cloud environment, or an edge computing device in an edge environment. Of course, the computing device 700 may also be a computer cluster formed by multiple devices. The computing device 700 is specifically configured to implement, for example, Figure 5 the interactive subsystem 102 as shown or Figure 6 the functions of the processing apparatus 600 for debug request messages as shown.

[0213] Figure 7 A structural schematic diagram of a computing device 700 is provided, as shown in Figure 7 FIG., the computing device 700 includes a bus 701, a processor 702, a communication interface 703, and a memory 704. The processor 702, the memory 704, and the communication interface 703 communicate with each other through the bus 701.

[0214] The bus 701 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 7 only a thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0215] The processor 702 can be any one or more of processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0216] The communication interface 703 is used for external communication. For example, when implementing Figure 5 the functions of the interaction subsystem 102 shown, the communication interface 703 is used to send multiple debugging request messages to the routing subsystem 104 for the identifiers of multiple sub-application modules for user input or selection, etc. Also for example, when implementing Figure 6 the functions of the debugging request message processing device 600 shown, the communication interface 703 is used to receive multiple original debugging request messages, send multiple debugging request messages, etc.

[0217] The memory 704 can include volatile memory, such as random access memory (RAM). The memory 704 can also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0218] Executable code is stored in the memory 704, and the processor 702 executes the executable code to perform the methods in the foregoing embodiments.

[0219] When implementing Figure 5 the embodiments shown, and Figure 5 when each unit of the interaction subsystem 102 described in the embodiments is implemented by software, the software or program code required to execute the functions of the creation unit 1024 and the generation unit 1026 in Figure 5 is stored in the memory 704. The function of the communication unit 1022 is implemented through the communication interface 703.

[0220] Specifically, the communication interface 703 receives the identifiers of multiple sub-application modules for user input or selection, and transmits the identifiers of multiple sub-application modules for user input or selection to the processor 702 through the bus 701. The processor 702 executes the program code in the memory 704, thereby creating multiple debugging sessions and generating multiple debugging request messages based on the multiple debugging sessions.

[0221] In the case of implementing Figure 6 the embodiment shown, and Figure 6 when each unit of the processing device 600 for the debug request message described in the embodiment shown is implemented by software, execute Figure 6 the software or program code required for the functions of the creation unit 604 and the generation unit 606 in

[0222] is stored in the memory 704. The function of the communication unit 602 is implemented through the communication interface 703.

[0223] An embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive), etc. The computer-readable storage medium includes instructions that direct the computing device to execute the above-mentioned application debugging method or the processing method of the debug request message.

[0224] An embodiment of the present application also provides a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computing device, the processes or functions according to the embodiments of the present application are fully or partially generated.

[0225] The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, or data center to another website, computer, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or a wireless manner (such as infrared, wireless, microwave, etc.).

[0226] The computer program product can be a software installation package. In the case where any method of the foregoing application debugging method or the processing method of the debug request message is required, the computer program product can be downloaded and executed on the computing device.

[0227] The descriptions of the processes or structures corresponding to the above-mentioned respective drawings each have their own focuses. For parts not elaborated in a certain process or structure, reference can be made to the relevant descriptions of other processes or structures.

Claims

1. An application debugging method, characterized in that, The method is applied to an application debugging system for code debugging of sub - application modules of an application. The application debugging system includes a routing subsystem and an interaction subsystem. The method includes: The interaction subsystem receives the identifiers of multiple sub - application modules input or selected by a user. Each sub - application module includes code blocks for implementing the functions of the application; The interaction subsystem creates multiple debugging sessions, and the multiple debugging sessions correspond one - to - one with the multiple sub - application modules; The interaction subsystem generates multiple debugging request messages according to the multiple debugging sessions. Each debugging request message in the multiple debugging request messages is generated based on the Debugging Adaptation Protocol (DAP). Each debugging request message is routed by the routing subsystem to the proxy of the sub - application module to be debugged based on the debugging session identifier for requesting to debug the code blocks of the corresponding sub - application module.

2. The method according to claim 1, characterized in that, Each debugging session includes a debugging session identifier. The interaction subsystem generates multiple debugging request messages according to the multiple debugging sessions, including: The interaction subsystem generates multiple original debugging request messages according to the identifiers of multiple sub - application modules; The interaction subsystem adds the debugging session identifier corresponding to the sub - application module to be debugged to the multiple original debugging request messages to obtain multiple debugging request messages.

3. The method according to claim 2, characterized in that, The method further includes: The interaction subsystem creates a global debugging session, and the global debugging session corresponds to the multiple debugging sessions; The interaction subsystem adds the debugging session identifier corresponding to the sub - application module to be debugged to the multiple original debugging request messages to obtain multiple debugging request messages, including: The interaction subsystem adds the debugging session identifier corresponding to the sub - application module to be debugged and the global debugging session identifier to the multiple original debugging request messages to generate multiple debugging request messages.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The interaction subsystem receives multiple debugging response messages, and the multiple debugging response messages correspond one - to - one with the multiple debugging request messages.

5. The method according to any one of claims 1 to 3, characterized in that, Before sending the multiple debugging request messages to the routing subsystem, the method further includes: The interaction subsystem establishes a long - term connection with the routing subsystem.

6. The method according to claim 5, characterized in that, The method further includes: When the establishment of the long - term connection fails, the interaction subsystem discards the received debugging request messages.

7. The method according to any one of claims 1 to 3, characterized in that, The method further includes: When the multiple debugging sessions are closed, the interaction subsystem disconnects the long - term connection with the routing subsystem.

8. A method for processing a debugging request message, characterized in that, The method includes: The debugging adapter receives multiple original debugging request messages. Each original debugging request message is used to request to debug a sub - application module of an application. Each sub - application module includes code blocks for implementing the functions of the application; The debugging adapter creates multiple debugging sessions, and the multiple debugging sessions correspond one - to - one with the multiple sub - application modules to be debugged; The debug adapter generates a plurality of debug request messages according to the debug session identifiers corresponding to the plurality of debug sessions and the plurality of original debug request messages, and sends the plurality of debug request messages. Each debug request message in the plurality of debug request messages is generated based on the Debug Adapter Protocol (DAP), and each debug request message is routed by a routing subsystem to a proxy of a sub-application module requesting debugging for requesting to debug a code block of the corresponding sub-application module.

9. The method according to claim 8, characterized in that, The debug adapter generates a plurality of debug request messages according to the debug session identifiers corresponding to the plurality of debug sessions and the plurality of original debug request messages, including: The debug adapter adds the debug session identifier corresponding to the sub-application module requesting debugging to the plurality of original debug request messages to obtain a plurality of debug request messages.

10. The method according to claim 9, characterized in that, The method further includes: The debug adapter creates a global debug session, and the global debug session corresponds to the plurality of debug sessions; The debug adapter adds the debug session identifier corresponding to the sub-application module requesting debugging to the plurality of original debug request messages to obtain a plurality of debug request messages, including: The debug adapter adds the debug session identifier corresponding to the sub-application module requesting debugging and the global debug session identifier to the plurality of original debug request messages to obtain a plurality of debug request messages.

11. The method according to claim 9, characterized in that,The debug adapter adds the debug session identifier corresponding to the sub-application module requesting debugging to the plurality of original debug request messages, including: The debug adapter deletes the standard message headers of the plurality of original debug request messages; The debug adapter adds updated message headers to the plurality of original debug request messages, and the updated message headers include the debug session identifier corresponding to the sub-application module requesting debugging.

12. The method according to any one of claims 8 to 11, characterized in that, The method further includes: The debug adapter receives a plurality of debug response messages, and the plurality of debug response messages correspond one-to-one to the plurality of debug request messages.

13. The method according to claim 12, characterized in that, The method further includes: The debug adapter deletes the message headers of the plurality of debug response messages, and the message headers of the debug response messages include debug session identifiers; The debug adapter adds standard message headers to the plurality of debug response messages.

14. The method according to any one of claims 8 to 11, characterized in that, Before the debug adapter sends the plurality of debug request messages, the method further includes: The debug adapter establishes a long connection with the routing subsystem, and the routing subsystem is used to route the debug request messages to a proxy of a sub-application module requesting debugging.

15. The method according to claim 14, characterized in that, The method further includes: When the establishment of the long connection fails, the debug adapter discards the received debug request messages.

16. The method according to any one of claims 8 to 11, characterized in that, The method further includes: When the plurality of debug sessions are closed, the debug adapter disconnects from the routing subsystem.

17. An interaction subsystem, characterized in that, An application debug system is used to perform code debugging on sub-application modules of an application. The application debug system includes a routing subsystem and the interaction subsystem, and the interaction subsystem includes: A communication unit, configured to receive identifiers of a plurality of sub-application modules input or selected by a user. Each sub-application module includes code blocks for implementing functions of the application; Creation unit, used to create multiple debug sessions, where the multiple debug sessions correspond one-to-one with the multiple sub-application modules; Generation unit, used to generate multiple debug request messages according to the multiple debug sessions, each debug request message in the multiple debug request messages is generated based on the Debug Adaptation Protocol (DAP), and each debug request message is routed by the routing subsystem to the proxy of the sub-application module requesting debugging based on the debug session identifier, for requesting to debug the code block of the corresponding sub-application module.

18. The subsystem according to claim 17, characterized in that, Each debug session includes a debug session identifier, and the generation unit is specifically used for: Generating multiple original debug request messages according to the identifiers of the multiple sub-application modules; Adding the debug session identifier corresponding to the sub-application module requesting debugging to the multiple original debug request messages to obtain multiple debug request messages.

19. The subsystem according to claim 18, characterized in that, The creation unit is further used for: Creating a global debug session, where the global debug session corresponds to the multiple debug sessions; The generation unit is specifically used for: Adding the debug session identifier corresponding to the sub-application module requesting debugging and the global debug session identifier to the multiple original debug request messages to generate multiple debug request messages.

20. The subsystem according to any one of claims 17 to 19, characterized in that, The communication unit is further used for: Receiving multiple debug response messages, where the multiple debug response messages correspond one-to-one with the multiple debug request messages.

21. The subsystem according to any one of claims 17 to 19, characterized in that, The subsystem further includes: Processing unit, used to establish a long connection with the routing subsystem before sending the multiple debug request messages to the routing subsystem.

22. The subsystem according to claim 21, wherein The processing unit is further used for: When the establishment of the long connection fails, discarding the received debug request messages.

23. The subsystem according to any one of claims 17 to 19, wherein The subsystem further includes: Processing unit, used to disconnect the long connection with the routing subsystem when the multiple debug sessions are closed.

24. A device for processing a debugging request message, wherein The device includes: Communication unit, used to receive multiple original debug request messages, each original debug request message is used to request to debug a sub-application module of the application, and the code block included in each sub-application module is used to implement the function of the application; Creation unit, used to create multiple debug sessions, where the multiple debug sessions correspond one-to-one with the multiple sub-application modules requesting debugging; Generation unit, used to generate multiple debug request messages according to the debug session identifiers corresponding to the multiple debug sessions and the multiple original debug request messages, and each debug request message in the multiple debug request messages is generated based on the Debug Adaptation Protocol (DAP); The communication unit is further used for sending the multiple debug request messages, and each debug request message is routed by the routing subsystem to the proxy of the sub-application module requesting debugging based on the debug session identifier, for requesting to debug the code block of the corresponding sub-application module.

25. The device according to claim 24, wherein The generation unit is specifically used for: Adding the debug session identifier corresponding to the sub-application module requesting debugging to the multiple original debug request messages to obtain multiple debug request messages.

26. The device according to claim 25, wherein The creation unit is further used for: Creating a global debug session, where the global debug session corresponds to the multiple debug sessions; The generation unit is specifically used for: Add the debugging session identifier corresponding to the sub - application module requesting debugging and the global debugging session identifier to the multiple original debugging request messages to obtain multiple debugging request messages.

27. The device according to claim 25, wherein The generating unit is specifically configured to: Delete the standard message headers of the multiple original debugging request messages; Add updated message headers to the multiple original debugging request messages, where the updated message headers include the debugging session identifier corresponding to the sub - application module requesting debugging.

28. The device according to any one of claims 24 to 27, wherein The communication unit is further configured to: Receive multiple debugging response messages, where the multiple debugging response messages correspond one - to - one with the multiple debugging request messages.

29. The device according to claim 28, wherein The generating unit is specifically configured to: Delete the message headers of the multiple debugging response messages, where the message headers of the debugging response messages include the debugging session identifier; Add standard message headers to the multiple debugging response messages.

30. The device according to any one of claims 24 to 27, wherein The device further includes: A processing unit, configured to establish a long - term connection with a routing subsystem, where the routing subsystem is used to route the debugging request messages to the proxy of the sub - application module requesting debugging.

31. The device according to claim 30, wherein The processing unit is further configured to: When the establishment of the long - term connection fails, discard the received debugging request messages.

32. The device according to any one of claims 24 to 27, whereinThe device further includes: A processing unit, configured to disconnect the connection with the routing subsystem when the multiple debugging sessions are closed.

33. A device, characterized in that, The device includes a processor and a memory; The processor is configured to execute the instructions stored in the memory to cause the device to execute the method according to any one of claims 1 to 7 or 8 to 16.

34. A computer-readable storage medium, characterized in that, Includes instructions that direct the device to execute the method according to any one of claims 1 to 7 or 8 to 16.

Images