Plugin data deletion method, server, electronic device, and storage medium

Abstract

Embodiments of the present invention relate to the field of communications, and more particularly to a method, server, electronic device, and storage medium for deleting plug-in data. The plug-in data management method includes: if it is detected that a plug-in is offline, determining the first node corresponding to the plug-in in a preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in; searching for the data of the plug-in according to the storage path identifier; and deleting the data of the plug-in. In the process of applying the plug-in offline, the purpose of locating and deleting all the data of the plug-in is achieved when the plug-in is hot-plugged offline, that is, without restarting the main project.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communications, and in particular to a method for deleting plug-in data, a server, an electronic device and a storage medium. Background Art

[0002] The plug-in launch and shutdown is based on JarsLink, an Alibaba open source framework. JarsLink (formerly known as Titan) is a Java-based modular development framework. Specifically, it implements plug-in launch and shutdown by providing dynamic module loading (a JAR package), module unloading, and application programming interface (API) for calling between modules at runtime. Currently, plug-in launch is achieved by creating a custom class loader, loading the components in the plug-in into the Spring container, and the container is embedded in the parent container of the main project as a child container; plug-in offline is to directly close the child container after a series of processing.

[0003] However, after the plug-in is offline, some data will remain in the memory. The main project cannot locate the specific location of the residual data in the memory, resulting in the inability to automatically delete the data, which will in turn affect the main project and seriously affect the existing business. This problem can only be solved by restarting the main project, which will interrupt the business. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a method, server, electronic device and storage medium for deleting plug-in data, which can locate and delete all data of the plug-in when the plug-in is hot-plugged and offline, that is, without restarting the main project.

[0005] To solve the above technical problems, an embodiment of the present invention provides a method for managing plug-in data, including: if it is detected that a plug-in is offline, determining the first node corresponding to the plug-in in a preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in; searching for the data of the plug-in according to the storage path identifier; and deleting the data of the plug-in.

[0006] An embodiment of the present invention also provides a server, comprising: a determination module, which, if it is detected that a plug-in is offline, determines the first node corresponding to the plug-in in a preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in; a search module, which is used to search for the data of the plug-in according to the storage path identifier; and a deletion module, which is used to delete the data of the plug-in.

[0007] An embodiment of the present invention further provides an electronic device, including:

[0008] at least one processor; and,

[0009] a memory communicatively connected to the at least one processor; wherein,

[0010] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned method for deleting plug-in data.

[0011] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, wherein the computer program implements the above-mentioned method for deleting plug-in data when executed by a processor.

[0012] Compared with the prior art, the embodiments of the present invention can determine the first node corresponding to the plug-in in a preset data structure, i.e., a multi-branch tree, when detecting that a plug-in is offline, and then directly locate and find the data of the plug-in according to a storage path identifier carried by the first node for indicating the data storage location of the plug-in, and finally delete the found data of the plug-in, thereby achieving the purpose of locating and deleting all the data of the plug-in when the plug-in is hot-plugged offline, i.e., without restarting the main project, and solving the problem that the residual data of the plug-in offline can only be cleared unless the main project is restarted.

[0013] In addition, the method for deleting plug-in data provided by the embodiment of the present invention, if the plug-in is detected to be offline, before determining the first node corresponding to the plug-in in the preset multi-branch tree, further includes: when the plug-in is online, obtaining and saving the data of the plug-in; creating the first node in the preset multi-branch tree according to the data of the plug-in and generating the storage path identifier. It is possible to create a node and generate a path identifier for searching the plug-in data when the plug-in is offline later.

[0014] In addition, the method for deleting plug-in data provided by the embodiment of the present invention, before creating the first node in the preset multi-branch tree according to the plug-in data and generating the storage path identifier, also includes: after the main project to which the plug-in belongs is started, obtaining the metadata of the main project; creating a second node in the preset multi-branch tree according to the metadata; creating the first node in the preset multi-branch tree according to the plug-in data and generating the storage path identifier, including: creating a child node of the second node in the preset multi-branch tree as the first node according to the plug-in data; generating the storage path identifier. After the main project is started, a corresponding second node is created for the main project, and then when the plug-in goes online, the first node is created by creating a child node for the second node, thereby determining the corresponding relationship between the main project and the plug-in, and facilitating the management of several plug-ins by different main projects.

[0015] In addition, the method for deleting plug-in data provided by the embodiment of the present invention, if the plug-in is detected to be offline, before determining the first node corresponding to the plug-in in the preset multi-branch tree, further includes: registering an event listener for the first node; and using the event listener to monitor the plug-in. By setting the event listener to monitor the first node, thereby monitoring the plug-in corresponding to the first node, the working status of the plug-in can be perceived in a timely and accurate manner, so as to process the plug-in data accordingly.

[0016] In addition, the method for deleting plug-in data provided by the embodiment of the present invention, wherein the plug-in is monitored by the event listener, comprises: using the event listener to monitor whether a heartbeat packet sent by the plug-in is not received within a preset time length; if so, determining that the plug-in is offline; if not, determining that the plug-in is online. The working status of the plug-in is sensed in real time through the heartbeat packet, and the data of the offline plug-in is processed in time to avoid occupying resources.

[0017] In addition, the method for deleting plug-in data provided by the embodiment of the present invention, after the plug-in is monitored by the event listener, further includes: if the plug-in is monitored by the event listener to be called, obtaining the storage path identifier carried by the first node; obtaining the data of the plug-in according to the storage path identifier; routing the data of the plug-in to the plug-in and notifying the plug-in to execute the task. When the plug-in and the plug-in data are not deployed to the same location, it is still possible to respond to the scheduling needs of the main project in a timely and accurate manner and execute tasks.

[0018] In addition, the method for deleting plug-in data provided by the embodiment of the present invention, after routing the plug-in data to the plug-in and notifying the plug-in to execute the task, further includes: obtaining the operation data generated in the process of the plug-in executing the task; and updating the plug-in data according to the operation data. New data will be generated in the process of the plug-in executing the task, and the plug-in data will be updated using the newly generated data, which ensures the real-time and integrity of the saved plug-in data, so that by deleting the plug-in data when going offline, all data generated in the entire process from going online to going offline can be completely cleared, further avoiding data residue. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0020] Figure 1 is a flowchart of a method for deleting plug-in data provided by a first embodiment of the present invention;

[0021] Figure 2 is a flowchart of a method for deleting plug-in data provided by a second embodiment of the present invention;

[0022] Figure 3 is a flowchart of a method for deleting plug-in data provided by a third embodiment of the present invention;

[0023] Figure 4 yes Figure 3 The multi-tree structure diagram involved in step 302 of the method for deleting plug-in data provided by the third embodiment of the present invention is shown;

[0024] Figure 5 is a flowchart of a method for deleting plug-in data provided by a fourth embodiment of the present invention;

[0025] Figure 6 yes Figure 5 The flowchart of step 504 in the method for deleting plug-in data provided by the fourth embodiment of the present invention is shown;

[0026] Figure 7 is a flowchart of a method for deleting plug-in data provided by a fifth embodiment of the present invention;

[0027] Figure 8 is a schematic structural diagram of a server provided by a sixth embodiment of the present invention;

[0028] Fig. 9 It is a schematic structural diagram of an electronic device provided by the seventh embodiment of the present invention. DETAILED DESCRIPTION

[0029] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.

[0030] The first embodiment of the present invention relates to a method for deleting plug-in data, which is applied to a server, and the process is as follows: Figure 1 As shown, including:

[0031] Step 101: If it is detected that a plug-in is offline, determine the first node corresponding to the plug-in in a preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in.

[0032] In this embodiment, the preset multi-branch tree is the data structure involved in the present invention, and there is a one-to-one correspondence between the first node in the multi-branch tree and the plug-in. When a plug-in is detected to be offline, the first node corresponding to the plug-in in the multi-branch tree can be uniquely determined based on the one-to-one correspondence between the plug-in and the first node.

[0033] In this embodiment, the plug-in data is the currently saved data related to the plug-in, such as the metadata of the plug-in, the data necessary for the plug-in to run, etc. Of course, the above is only a specific example, and in the actual use process, the plug-in data may also include other plug-in related data, which will not be described one by one here.

[0034] This implementation does not limit the storage path identifier. In actual use, the storage path identifier can be any identifier that can uniquely indicate the data storage location of the plug-in.

[0035] Step 102: Search for plug-in data according to the storage path identifier.

[0036] In this implementation, since the storage path identifier indicates the storage location of the plug-in data, the plug-in data can be directly found according to the storage path identifier.

[0037] Step 103, delete the plug-in data.

[0038] In this embodiment, the data of all found plug-ins are deleted.

[0039] Compared with the prior art, the embodiments of the present invention can determine the first node corresponding to the plug-in in a preset data structure, i.e., a multi-branch tree, when detecting that a plug-in is offline, and then directly locate and find the data of the plug-in according to a storage path identifier carried by the first node for indicating the data storage location of the plug-in, and finally delete the found data of the plug-in, thereby achieving the purpose of locating and deleting all data of the plug-in when the plug-in is hot-plugged offline, i.e., without restarting the main project, and solving the problem that the residual data of the plug-in offline can only be cleared unless the main project is restarted.

[0040] The second embodiment of the present invention relates to a method for deleting plug-in data, which is basically the same as the method for deleting plug-in data provided by the first embodiment of the present invention, except that it further includes how to create a first node, such as Figure 2 As shown, including:

[0041] Step 201: When the plug-in goes online, the data of the plug-in is obtained and saved.

[0042] In this embodiment, when the plug-in goes online, a long connection is established between the plug-in and the server through a three-way handshake protocol. The plug-in sends the current plug-in data to the server through the long connection for the server to receive and save to the server's storage space.

[0043] It should be noted that when saving the data of the plug-in, the data of the complex and error-prone plug-in can be encapsulated to generate an efficient and reliable primitive set. When the main project to which the plug-in belongs needs to call the plug-in to perform a task, the relevant primitives are directly provided to the plug-in in a series of simple and easy-to-use interfaces. At the same time, considering that the efficiency of the disk is lower than that of the memory, the plug-in data can be saved in the memory. In particular, when the server is deployed in a cluster to achieve high availability, since the write operation requires all servers to be in a synchronized state, it will show high performance in the task scenario where the read operation is more than the write operation.

[0044] Step 202: Create a first node in a preset multi-branch tree according to the data of the plug-in and generate a storage path identifier.

[0045] In this implementation, the preset multi-branch tree is the data model used by the server. Each node in the multi-branch tree consists of two parts. The first part is the state information, including the creation time, modification time, number of child nodes of the current node, etc.; the second part is the data part, including the path identifier, plug-in name, etc. Of course, the above is only a specific example. In the actual implementation process, the composition of each node can also include other contents, which will not be described here one by one.

[0046] It should be noted that each node in the multi-branch tree can store data, and the data stored by the node can be numbers, strings, or binary sequences, etc. However, the node can also be used not to store data, but to store data that serves as an identifier, such as the name of the plug-in, to identify the node in order to distinguish different nodes or data corresponding to the node. When the node stores identification data, there is no need for the node to save the plug-in data, especially the task data. It can be considered that the node here is mainly used to manage the plug-in data, or to coordinate services through the management of the plug-in data. Therefore, a threshold value can be set for the size of the data stored on the node, such as 1M, which ensures the amount of data stored on the node, facilitates fast network transmission, and does not occupy a large amount of network bandwidth.

[0047] Step 203: If it is detected that the plug-in is offline, determine the first node corresponding to the plug-in in the preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in.

[0048] Step 203 of this embodiment is substantially the same as step 101 of the first embodiment, and will not be described in detail here.

[0049] Step 204: search for plug-in data according to the storage path identifier.

[0050] Step 204 of this embodiment is substantially the same as step 102 of the first embodiment, and will not be described in detail here.

[0051] Step 205: Delete the plug-in data.

[0052] Step 205 of this embodiment is substantially the same as step 101 of the first embodiment, and will not be described in detail here.

[0053] Compared with the prior art, the embodiments of the present invention can create nodes and generate path identifiers for subsequent plug-in search when the plug-in goes offline, based on the beneficial effects brought by the first embodiment.

[0054] The third embodiment of the present invention relates to a method for deleting plug-in data, which is basically the same as the method for deleting plug-in data provided in the second embodiment of the present invention, except that a node is also created according to the main project to which the plug-in belongs, such as Figure 3 As shown, including:

[0055] Step 301, after the main project to which the plug-in belongs is started, metadata of the main project is obtained.

[0056] In this implementation, after a main project is started, the main project will register its own main project data with the server, wherein the main project data includes metadata of the main project and the like.

[0057] Step 302: Create a second node in a preset multi-branch tree according to the metadata.

[0058] In this embodiment, the creation of the second node is substantially the same as the creation of the first node. After executing step 304, the following is obtained: Figure 4 The structure diagram of the multi-branch tree shown in FIG. 1 shows a diagram of a multi-branch tree, in which the second node is a child node of the original root node of the preset multi-branch tree, and the first node created in the following step 304 is a child node of the second node. The original root node of the multi-branch tree may have several child nodes, and each second node may also have several child nodes.

[0059] It should be noted that in the actual implementation process, there are two types of nodes in the multi-branch tree: persistent nodes and temporary nodes. Persistent nodes are equivalent to the second node. Once created, they always exist, and their existence will not be affected even if the server or server cluster crashes. Temporary nodes are equivalent to the first node. Their life cycle is bound to the long connection between the server and the plug-in. If the long connection disappears, the node disappears. In addition, temporary nodes can only be leaf nodes and cannot continue to create child nodes.

[0060] It should be noted that the present embodiment does not limit the specific execution locations of step 301 and step 302. In the present embodiment, for ease of understanding, the execution of step 301 and step 302 before step 303 is used as an example for description. In actual use, step 301 and step 302 can be executed before step 304, and each case will not be described one by one here.

[0061] Step 303: When the plug-in goes online, the data of the plug-in is obtained and saved.

[0062] Step 303 of this embodiment is substantially the same as step 201 of the second embodiment, and will not be described in detail here.

[0063] Step 304: Create a first node in a preset multi-branch tree according to the plug-in data and generate a storage path identifier.

[0064] Step 304 of this embodiment is substantially the same as step 202 of the second embodiment, and will not be described in detail here.

[0065] Step 305: If it is detected that the plug-in is offline, determine the first node corresponding to the plug-in in the preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier indicates the data storage location of the plug-in.

[0066] Step 305 of this embodiment is substantially the same as step 203 of the first embodiment, and will not be described in detail here.

[0067] Step 306: Search for plug-in data according to the storage path identifier.

[0068] Step 306 of this embodiment is substantially the same as step 204 of the first embodiment, and will not be described in detail here.

[0069] Step 307, delete the plug-in data.

[0070] Step 307 of this embodiment is substantially the same as step 205 of the first embodiment, and will not be described in detail here.

[0071] Compared with the prior art, the implementation mode of the present invention, on the basis of achieving the beneficial effects brought by the first implementation mode, after the main project is started, a corresponding second node is created for the main project, and then when the plug-in is online, the creation of the first node is achieved by creating a child node for the second node. The multi-level multi-branch tree structure facilitates the management of corresponding plug-ins by different main projects, and can clearly and accurately reflect the connection between main projects and main projects, and main projects and plug-ins.

[0072] The fourth embodiment of the present invention relates to a method for deleting plug-in data. The method is basically the same as the method for deleting plug-in data provided in the second embodiment of the present invention, except that the working status of the plug-in can also be obtained. Figure 5 As shown, including:

[0073] Step 501: When the plug-in goes online, the data of the plug-in is obtained and saved.

[0074] Step 501 of this embodiment is substantially the same as step 201 of the second embodiment, and will not be described in detail here.

[0075] Step 502: Create a first node in a preset multi-branch tree according to the data of the plug-in and generate a storage path identifier.

[0076] Step 502 of this embodiment is substantially the same as step 202 of the second embodiment, and will not be described in detail here.

[0077] Step 503: register an event listener for the first node.

[0078] In this embodiment, the server allows the plug-in to register some event listeners on the specified node. Specifically, the user is interested in certain events related to the plug-in, such as the plug-in going offline, etc., so a request to create a listener for the events of interest to the plug-in is sent through the long connection between the plug-in and the server, so that the server can set an event listener for the node specified in the request to listen to the events of interest to the plug-in.

[0079] Step 504: Use the event listener to monitor the plug-in corresponding to the first node to obtain the working status of the plug-in, where the working status includes online and offline.

[0080] Specifically, Figure 6 As shown, step 504 may include:

[0081] Step 601: Use an event listener to monitor whether a heartbeat packet sent by the plug-in is not received within a preset time.

[0082] In this embodiment, if yes, execute step 602, and if no, execute step 603.

[0083] Specifically, a heartbeat mechanism is applied between the plug-in and the server. The plug-in sends a heartbeat packet to the server through the long connection between the plug-in and the server every preset period, such as 30 seconds, and then the server receives the heartbeat packet to determine that the long connection between the plug-in and the server is a valid (surviving) connection. The event listener monitors the process of the server receiving the heartbeat packet as described above. At the same time, the server can also scan all surviving connections every preset period, such as 60 seconds, to further determine the working status of the plug-in.

[0084] Step 602: Determine that the working state of the plug-in is offline.

[0085] In this embodiment, if the event listener detects that the server has not received the heartbeat packet from the plug-in within a preset time length, such as 2 minutes, that is, the connection between the plug-in and the server is invalid, it is determined that the plug-in is offline and the connection between the plug-in and the server is disconnected.

[0086] Step 603: Determine that the working status of the plug-in is online.

[0087] Step 505: If it is detected that the plug-in is offline, determine the first node corresponding to the plug-in in the preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in.

[0088] Step 505 of this embodiment is substantially the same as step 203 of the first embodiment, and will not be described in detail here.

[0089] Step 506: Search for plug-in data according to the storage path identifier.

[0090] Step 506 of this embodiment is substantially the same as step 204 of the first embodiment, and will not be described in detail here.

[0091] Step 507, delete the plug-in data.

[0092] Step 507 of this embodiment is substantially the same as step 205 of the first embodiment, and will not be described in detail here.

[0093] Compared with the prior art, the embodiments of the present invention, on the basis of achieving the beneficial effects brought by the first embodiment, monitor the first node by setting an event listener, thereby monitoring the plug-in corresponding to the first node, so that the working status of the plug-in can be perceived in a timely and accurate manner, so as to perform corresponding processing on the data of the plug-in.

[0094] The fifth embodiment of the present invention relates to a method for deleting plug-in data, which is basically the same as the method for deleting plug-in data provided by the first embodiment of the present invention, except that it also includes updating the plug-in data, such as Figure 7 As shown, it also includes:

[0095] Step 701: register an event listener for the first node.

[0096] Step 702: Monitor the plug-in using an event listener.

[0097] Step 703: If the event listener detects that the plug-in is called, the storage path identifier carried by the first node is obtained.

[0098] Step 704: Obtain the plug-in data according to the storage path identifier.

[0099] Step 705: Routing the plug-in data to the plug-in and notifying the plug-in to execute the task.

[0100] In this embodiment, the server sends the data of the plug-in to the plug-in through the long connection between the server and the plug-in and notifies the plug-in to execute the task at the same time.

[0101] It should be noted that what is sent to the plug-in may also be the data required to execute the task rather than all the data of the plug-in.

[0102] Step 706: Obtain the operation data generated during the plug-in's task execution.

[0103] In this embodiment, the running data is data generated by the plug-in during its running process and needs to be saved.

[0104] Step 707: Update the plug-in data according to the running data.

[0105] In this embodiment, the running data is added to the data of the plug-in to update the data of the plug-in, and the data generated by the plug-in is synchronized to the server.

[0106] Step 708: If it is detected that the plug-in is offline, determine the first node corresponding to the plug-in in the preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in.

[0107] Step 708 of this embodiment is substantially the same as step 203 of the first embodiment, and will not be described in detail here.

[0108] Step 709: Search for plug-in data according to the storage path identifier.

[0109] Step 709 of this embodiment is substantially the same as step 204 of the first embodiment, and will not be described in detail here.

[0110] Step 710, delete the plug-in data.

[0111] Step 710 of this embodiment is substantially the same as step 205 of the first embodiment, and will not be described in detail here.

[0112] Compared with the prior art, the embodiment of the present invention can achieve the beneficial effects brought by the first embodiment. On the one hand, the running data of the plug-in can be synchronized to the server, so that when the data of the plug-in is deleted, all the data of the plug-in can be deleted without omission. On the other hand, when the plug-in and the plug-in data are not deployed to the same location, it can still respond to the scheduling needs of the main project in a timely and accurate manner and execute tasks.

[0113] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0114] A sixth embodiment of the present invention relates to a server, such as Figure 8 As shown, including:

[0115] The determination module 801 determines the first node corresponding to the plug-in in a preset multi-branch tree if it is detected that the plug-in is offline, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in.

[0116] The search module 802 is used to search for the data of the plug-in according to the storage path identifier.

[0117] The deletion module 803 is used to delete the data of the plug-in.

[0118] It is not difficult to find that this embodiment is a server embodiment corresponding to the first embodiment, and this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the first embodiment.

[0119] It is worth mentioning that all modules involved in this embodiment are logic modules. In practical applications, a logic unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of the present invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by the present invention, but this does not mean that there are no other units in this embodiment.

[0120] A seventh embodiment of the present invention relates to an electronic device, such as Fig. 9 As shown, including:

[0121] at least one processor 901; and,

[0122] A memory 902 that is communicatively connected to the at least one processor 901; wherein,

[0123] The memory 902 stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor 901 so that the at least one processor 901 can execute the method for deleting plug-in data described in the first to fifth embodiments of the present invention.

[0124] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0125] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0126] The eighth embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0127] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0128] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A method for deleting plug-in data, characterized in that: include: If it is detected that the working state of the plug-in is offline, determine a first node corresponding to the plug-in in a preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate a data storage location of the plug-in; Searching for data of the plug-in according to the storage path identifier, wherein the data of the plug-in is all data currently stored and related to the plug-in; Deleting the data of said plugin; If the working state of the plug-in is detected to be offline, before determining the first node corresponding to the plug-in in the preset multi-branch tree, the method further includes: when the plug-in is online, obtaining and saving the data of the plug-in; creating the first node in the preset multi-branch tree according to the data of the plug-in and generating the storage path identifier; If the working state of the plug-in is detected to be offline, before determining the first node corresponding to the plug-in in the preset multi-branch tree, the method further includes: registering an event listener for the first node; The plug-in is monitored using the event listener; the monitoring of the plug-in using the event listener includes: using the event listener to monitor whether a heartbeat packet sent by the plug-in is not received within a preset time length; if so, determining that the working status of the plug-in is offline; if not, determining that the working status of the plug-in is online.

2. The method according to claim 1, characterized in that Before creating the first node in the preset multi-branch tree according to the data of the plug-in and generating the storage path identifier, the method further includes: After the main project to which the plug-in belongs is started, obtaining metadata of the main project; Creating a second node in the preset multi-branch tree according to the metadata; The step of creating the first node in the preset multi-branch tree according to the data of the plug-in and generating the storage path identifier includes: Creating a child node of the second node as the first node in the preset multi-branch tree according to the data of the plug-in; The storage path identifier is generated.

3. The method according to claim 1, characterized in that After the plug-in is monitored by the event listener, the method further includes: If the event listener is used to monitor that the plug-in is called, obtaining the storage path identifier carried by the first node; Acquire data of the plug-in according to the storage path identifier; Routing the data of the plug-in to the plug-in and notifying the plug-in to perform tasks.

4. The method according to claim 3, characterized in that After routing the plug-in data to the plug-in and notifying the plug-in to execute the task, the method further includes: Obtaining the running data generated during the execution of the task by the plug-in; The data of the plug-in is updated according to the running data.

5. A server, characterized in that: include: The determination module, if it is detected that the working state of the plug-in is offline, determines the first node corresponding to the plug-in in the preset multi-branch tree, wherein the first node carries a storage path identifier, and the storage path identifier is used to indicate the data storage location of the plug-in; if it is detected that the working state of the plug-in is offline, before determining the first node corresponding to the plug-in in the preset multi-branch tree, it also includes: when the plug-in is online, obtaining and saving the data of the plug-in; creating the first node in the preset multi-branch tree according to the data of the plug-in and generating the storage path identifier; if it is detected that the working state of the plug-in is offline, before determining the first node corresponding to the plug-in in the preset multi-branch tree, it also includes: registering an event listener for the first node; using the event listener to monitor the plug-in; using the event listener to monitor the plug-in, including: using the event listener to monitor whether the heartbeat packet sent by the plug-in is not received within a preset time length; if so, determining that the working state of the plug-in is offline; if not, determining that the working state of the plug-in is online; A search module, used for searching the data of the plug-in according to the storage path identifier, wherein the data of the plug-in is all data currently stored and related to the plug-in; The deletion module is used to delete the data of the plug-in.

6. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method for deleting plug-in data as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for deleting plug-in data according to any one of claims 1 to 4 is implemented.

Images