System task exception processing method and device

Abstract

The invention provides a system task exception processing method and device, and relates to the technical field of computers. Wherein the state variables comprise a first state variable for identifying whether the metadata repair process is executed or not, and a second state variable for identifying that the repair operation of the metadata repair process is completed and passes verification; determining whether the metadata state variable meets a preset abnormal state condition or not; and under the condition that the metadata state variable meets the preset abnormal state condition, executing a first decision. In this way, diversified decisions are made according to the combination condition of the two state variables through the state variables of the two metadata with the internal logical association. According to the method, a single state mark can be replaced, and a finer and safer behavior decision can be made, so that a normal background task can be prevented from being hung unnecessarily, the continuous service capability of the system is improved, and the robustness of the system is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method and device for handling system task exceptions. Background Technology

[0002] In related technologies, centralized storage systems, as high-performance, highly consistent, and easy-to-manage systems, have been widely used. Centralized storage systems typically require coordinated handling of normal and abnormal tasks. Currently, a single status flag is commonly used to coordinate normal tasks and abnormal processes. If the flag is true, the system immediately interrupts its own processing flow and jumps to a unified error handling branch, entering a waiting or suspended state, hoping to be awakened after the fault recovery process is completed. This approach is coarse-grained and can easily lead to many normal background tasks being unnecessarily suspended, reducing the system's continuous service capability during faults. Summary of the Invention

[0003] This disclosure provides a method and device for handling system task anomalies. Its main purpose is to solve the problem of poor continuous service capability of the system during failures.

[0004] According to a first aspect of this disclosure, a system task exception handling method is provided, comprising: Obtain metadata status variables; among which, the status variables include a first status variable that indicates whether the metadata repair process is in progress, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified. Determine whether the metadata status variable meets the preset abnormal status conditions; wherein, the preset abnormal status conditions include at least one of the following: the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation is not completed or the verification has failed; If the metadata state variable satisfies the preset abnormal state condition, the first decision is executed.

[0005] According to a second aspect of this disclosure, a system task exception handling apparatus is provided, comprising: The acquisition module is used to acquire metadata status variables; among which, the status variables include a first status variable that indicates whether the metadata repair process is being executed, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified. The determination module is used to determine whether the metadata status variable meets the preset abnormal status conditions; wherein, the preset abnormal status conditions include at least one of the following: the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation is not completed or the verification has failed; The execution module is used to execute the first decision when the metadata state variables meet the preset abnormal state conditions.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect above.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect above.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0009] In the embodiments provided in this disclosure, metadata status variables are obtained; these status variables include a first status variable indicating whether the metadata repair process is in progress, and a second status variable indicating that the repair operation of the metadata repair process has been completed and verified. It is then determined whether the metadata status variables meet preset abnormal state conditions, which include at least one of the following: the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation has not been completed or verification has failed. If the metadata status variables meet the preset abnormal state conditions, a first decision is executed. In this way, by using two metadata status variables with inherent logical correlation, diversified decisions are made based on the combination of the two status variables. This can replace a single status flag, making more refined and secure behavioral decisions, thereby avoiding unnecessary suspension of normal background tasks, improving the system's continuous service capability, and enhancing system robustness.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A flowchart illustrating a system task exception handling method provided for related technologies; Figure 2A flowchart illustrating a system task exception handling method provided in this embodiment of the disclosure; Figure 3 A flowchart illustrating a metadata repair process method provided in this embodiment of the disclosure; Figure 4 A flowchart illustrating a block space balancing task provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of a system task exception handling device provided in an embodiment of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] As the background technology indicates, centralized storage systems play a core role in enterprise-critical operations due to their high performance, strong consistency, and ease of management. To ensure high data reliability and efficient utilization of storage space, centralized storage systems typically run various background maintenance tasks (such as space balancing, snapshots, and data reduction) and real-time high-priority fault recovery processes (such as metadata repair and RAID (Redundant Array of Independent Disks) reconstruction). These tasks and processes share the system's limited resources (such as CPU (Central Processing Unit), memory, and I / O channels) and run concurrently within the same software stack.

[0014] In centralized storage architectures, the coupling between various modules (such as management, data, and metadata modules) is typically very high. This can lead to a typical problem: when the system is performing a routine space balancing task to optimize disk space layout, a metadata page verification error may be triggered due to minor disk media defects or memory errors. In this case, the system will immediately interrupt the current operation and jump to a high-priority metadata repair process. If the interruption of the normal task is not handled properly, it may cause the task to stall in some intermediate state, and the resources it occupies (such as locks, memory buffers, and task slots) may not be released. This could not only cause the task itself to fail but also block other operations that depend on these tasks, ultimately leading to task timeouts or the entire system service freezing, requiring manual intervention to recover. This could significantly impact the continuity and reliability of the storage service.

[0015] In related technologies, centralized storage systems typically use a single status flag (i.e., a global interrupt flag) bit to coordinate normal tasks and abnormal processes. For example, such as... Figure 1 As shown, when metadata corruption occurs, the system sets a global interrupt flag, `metadata_corrupt_flag`, in global memory. This flag (global interrupt flag) can be queried in callback functions of background tasks such as space balancing or in critical checkpoints. Once the flag is found to be true, the task will immediately interrupt its own process and jump to a unified error handling branch, usually entering a waiting or suspended state, hoping to be awakened after the fault repair process is completed.

[0016] This single-mark-based interruption mechanism has at least the following drawbacks in centralized storage systems: (1) Coarse-grained interruption and false positives: Once the mark (global interrupt mark) is set, its effect is global. Any background task that checks this mark before the repair is completed will be unconditionally interrupted, regardless of whether it is related to the fault point or whether it is in a state that can be safely interrupted. This strategy usually leads to many normal background tasks being unnecessarily suspended, reducing the system's continuous service capability during the fault. (2) Weakened system self-healing capability: It may lead to the interruption of normal tasks and the inability to release resources, causing the system's performance to drop sharply during the fault. After the high-priority repair process is completed, the system cannot quickly and automatically restore all background services, requiring a longer recovery time or even restarting the service.

[0017] Based on this, embodiments of this disclosure provide a system task exception handling method. This method introduces two state variables of metadata with inherent logical correlation, enabling diversified decision-making based on the combination of these two state variables. This replaces a single state flag, allowing for more refined and secure behavioral decisions. Consequently, it avoids unnecessary suspension of normal background tasks, thereby improving the system's continuous service capability and robustness.

[0018] The system task exception handling method and device of this disclosure are described below with reference to the accompanying drawings.

[0019] Figure 2 This is a flowchart illustrating a system task exception handling method provided in an embodiment of this disclosure. Figure 2 As shown, the system task exception handling method includes the following steps: Step 201: Obtain metadata status variables.

[0020] The status variables include a first status variable that indicates whether the metadata repair process is in progress, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified.

[0021] When handling system task exceptions, it's necessary to obtain metadata status variables. For example, this could involve obtaining a first status variable indicating whether the metadata repair process is in progress, and a second status variable indicating that the repair operation has been completed and verified. These two status variables can be set to false when the repair process starts and only set to true after the repair operation has been successfully executed and verified. For instance, when the metadata repair process begins, the first status variable is set to true; when the repair process ends, the first status variable is set to false; when the repair operation is completed and verified, the second status variable is set to true; otherwise, the second status variable remains false. As an example, the current metadata status variables can be obtained by setting an interface function (e.g., GetMetadataStatusVariables()).

[0022] Step 202: Determine whether the metadata status variables meet the preset abnormal status conditions.

[0023] The preset abnormal state conditions include at least one of the following: a first state variable indicating that the repair process is in progress, and a second state variable indicating that the repair operation is not completed or the verification has failed.

[0024] The preset abnormal state conditions can be customized according to actual needs. For example, the preset abnormal state conditions can be set by setting the values ​​of the first state variable and the second state variable to true or false. Correspondingly, after obtaining the metadata state variables, it can be determined whether the metadata state variables meet the preset abnormal state conditions. For example, whether the first state variable indicates that the repair process is in progress, and whether the second state variable indicates that the repair operation is not completed or the verification has failed. By determining the values ​​of the first state variable and the second state variable, it can be determined whether the metadata state variables meet the preset abnormal state conditions.

[0025] As an example, preset abnormal state conditions may include a first state variable indicating that the repair process is in progress (e.g., first state variable = true), and a second state variable indicating whether the repair operation is incomplete or verification failed (e.g., second state variable is false). Determining whether a metadata state variable meets the preset abnormal state conditions may include determining whether the first state variable indicates that the repair process is in progress, and determining whether the second state variable indicates that the repair operation is incomplete or verification failed. Understandably, to determine whether a metadata state variable meets the preset abnormal state conditions, a logical judgment function can be designed. This function can determine whether the metadata state variable meets the abnormal state conditions based on the values ​​of the first and second state variables. As a concrete example, the logical judgment function can be defined as follows: This function accepts two Boolean parameters: the value of the first state variable and the value of the second state variable. The function returns a Boolean value indicating whether the abnormal state conditions are met. The logical judgment logic can be: if the first state variable is true, it means the repair process is in progress, meeting the abnormal state conditions; if the second state variable is false, it means the repair operation is incomplete or verification failed, meeting the abnormal state conditions. If neither condition is met, it means the state variable does not meet the abnormal state conditions. In this way, by defining metadata state variables and abnormal state conditions, and designing a logical judgment function, it is possible to effectively determine whether the metadata state variables meet the preset abnormal state conditions, thereby detecting abnormal situations in metadata in a timely manner, providing a basis for subsequent decision-making, and thus improving the stability and reliability of the system.

[0026] Step 203: If the metadata state variables meet the preset abnormal state conditions, execute the first decision.

[0027] The first decision can be a predefined decision, the specific content of which can be set according to actual needs, such as executing a task exit operation. If the metadata status variables meet the preset abnormal state conditions, that is, if the values ​​of the first and second status variables meet the preset abnormal state conditions, the first decision can be executed. For example, the first decision may include: pausing or terminating related data operations to prevent the abnormal state from further affecting the normal operation of the system; or it may include recording abnormal state information to a log file for subsequent analysis and troubleshooting; or sending an alert notification to the system administrator to remind them to pay attention to the abnormal situation of the metadata.

[0028] In the embodiments provided in this disclosure, metadata status variables are acquired; these status variables include a first status variable indicating whether the metadata repair process is in progress, and a second status variable indicating that the repair operation of the metadata repair process has been completed and verified. It is then determined whether the metadata status variables meet preset abnormal state conditions, which include at least one of the following: the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation has not been completed or verification has failed. If the metadata status variables meet the preset abnormal state conditions, a first decision is executed. In this way, by using two metadata status variables with inherent logical correlation, diversified decisions are made based on the combination of the two status variables. This can replace a single status flag, enabling more refined and secure behavioral decisions, thereby avoiding unnecessary suspension of normal background tasks, improving the system's continuous service capability, and enhancing system robustness.

[0029] In some possible implementations, if the metadata state variable meets a preset abnormal state condition, a first decision is executed, including: If the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation has not been completed or the verification has failed, then the task exit operation is executed.

[0030] The task exit operation includes releasing at least one of the following: all locks currently held by the current task, memory buffers, and system resources.

[0031] Specifically, after determining whether the first state variable indicates that the repair process is in progress, and whether the second state variable indicates that the repair operation is incomplete or the verification has failed, if the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation is incomplete or the verification has failed, then the metadata state variable can be determined to meet the preset abnormal state condition. At this point, a first decision can be executed, such as releasing all locks, memory buffers, and system resources currently held by the current task. Thus, by defining metadata state variables and abnormal state conditions, and executing the first decision when the conditions are met, abnormal situations in the metadata repair process can be effectively handled, enabling timely detection and handling of anomalies, preventing further errors or data corruption, and improving the stability and reliability of the system.

[0032] In some possible implementations, after determining whether the metadata state variable meets the preset abnormal state conditions, the method further includes: If the metadata state variables do not meet the preset abnormal state conditions, a second decision is executed; the second decision includes continuing to execute the current task.

[0033] In cases where the metadata state variables do not meet the preset abnormal state conditions, a second decision is executed, including: If the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has been verified, then the second decision is executed.

[0034] When the metadata state variables do not meet the preset abnormal state conditions, the second decision is executed, which also includes: If the first state variable indicates that there is no ongoing repair process, then execute the second decision.

[0035] If the metadata does not meet the preset abnormal state conditions—for example, the first state variable indicates that the repair process is in progress, and the second state variable indicates that the repair operation has been verified—meaning the combined state of the metadata state variables indicates that the core operation of metadata repair has been successfully completed and the system state has returned to stability; or, the first state variable indicates that there is no ongoing repair process, meaning the metadata state variables indicate that the system is completely normal and no metadata failure has occurred. In this case, a second decision can be executed. For example, the current environment can be determined to be safe, and the background task can be controlled to continue its normal execution process without any interruption or intervention. As an example, the logic to continue executing the current task can be defined as: continue executing the current metadata repair task, ensuring that the task proceeds normally until completion or a new exception is encountered. After determining that the metadata state variables do not meet the abnormal state conditions, the above logic is called to continue executing the current task. In this way, by defining metadata state variables and abnormal state conditions, and executing the continued execution of the current task when the abnormal state conditions are not met, the normal progress of the metadata repair process can be ensured, thereby effectively handling task execution under normal conditions, and taking timely measures when an exception is detected, further improving the stability and reliability of the system.

[0036] In some possible implementations, metadata state variables are obtained, including: When the task execution reaches the point where a process selection decision needs to be made, the metadata status variables are obtained.

[0037] In this context, considering the potential for multiple checkpoints or decision points during task execution—critical locations in the task flow where the next step needs to be determined based on the current state variables—the following steps are crucial: For example, a task might need to check the repair process halfway through execution to ensure its proper functioning, or it might need to decide whether to continue to the next stage after completing a certain phase. At these checkpoints or decision points, the current metadata state variable values ​​can be retrieved, i.e., the first and second state variables, to determine subsequent processing. As an example, during task execution, situations may arise where the next step needs to be determined based on the current state variable value. These situations typically include, but are not limited to: the task reaching a checkpoint requiring confirmation of the repair process's progress; the task reaching a decision point requiring selection of different execution paths based on the current repair status; and the task reaching an exception handling point requiring confirmation of whether the current repair status meets exception conditions. When a task reaches a point requiring a process selection decision, metadata status variables can be retrieved, and it can be determined whether these variables meet preset abnormal state conditions. If the metadata status variables meet the preset abnormal state conditions, the first decision (task exit operation) is executed; and if the metadata status variables do not meet the preset abnormal state conditions, the second decision (continue execution of the current task) is executed. Thus, by retrieving metadata status variables when the task reaches a point requiring a process selection decision, it is possible to better ensure that the task can make reasonable decisions based on its current recovery status, effectively handle various situations during task execution, and further improve the stability and reliability of the system.

[0038] In some possible implementations, after executing the first decision when the metadata state variable meets the preset abnormal state condition, the following steps are also included: The current task has entered a delayed retry state; the delayed retry state includes exiting the execution queue and retrying execution after a preset time.

[0039] In this system, after executing the first decision (i.e., exiting the task), the current task can be removed from the execution queue to prevent it from continuing. A preset delay time (e.g., 5 minutes) can also be set. After the delay expires, the task is added back to the execution queue for a second attempt. This delayed retry state after the first decision not only allows for timely detection and handling of anomalies but also enables retrying the task at an appropriate time, further improving system stability and reliability.

[0040] In a further possible implementation, after the current task enters the delayed retry state, the following is also included: Get the priority of the current task; Adjust the preset duration based on the priority of the current task.

[0041] After a task exits the execution queue, the retry duration can be adjusted based on the task's priority, i.e., the preset duration can be dynamically adjusted. For example, the priority of the current task can be obtained. If the current task has a high priority, such as higher than the preset priority, the preset duration can be shortened, for example, by adjusting it according to a set step size; conversely, if the current task has a low priority, such as lower than the preset priority, the preset duration can be increased. The specific priority setting can be configured according to actual conditions, and the specific value of the preset duration adjustment step size can also be configured according to actual needs.

[0042] In a further possible implementation, after the current task enters the delayed retry state, the following is also included: Retrieve historical retry data for the current task within a preset time period; the historical retry data includes the number of retries and the preset duration. If the number of retries exceeds a preset threshold, the retry strategy is adjusted; wherein, adjusting the retry strategy includes at least one of the following: Adjust the retry method for the current task; Adjust the preset duration.

[0043] After a task exits the execution queue, the retry strategy can be intelligently adjusted based on the task's historical retry data. For example, the number of retries and the preset duration (i.e., retry duration) for the current task within a preset time period can be obtained. The preset time period can be a set period from the current moment to the present moment. After obtaining the number of retries and the preset duration, the retry strategy for the current task can be adjusted based on these parameters, such as adjusting the retry method and the retry duration (i.e., the preset duration). For instance, if the number of failed retries for the current task within the preset time period exceeds the set number, the number of retries can be automatically reduced, and the retry interval can be increased, i.e., the preset duration can be increased, to avoid excessive pressure on the system due to frequent failures. Furthermore, the retry method can also be adjusted, such as based on the current task's priority, system load data, and the number of failed retries. For example, if system load data shows a low current load, a high priority for the current task, and fewer than a set number of failed retries, a linear retry method (i.e., a retries at fixed time intervals) can be used. Conversely, if system load data shows a high current load, a low priority for the current task, and more than the aforementioned set number of retries, an exponential retry method (i.e., a retry method with retry intervals increasing exponentially) can be used. In this way, by selecting an appropriate retry strategy based on the specific scenario, system stability and task recovery success rate can be improved.

[0044] To make the system task exception handling method provided in this disclosure clearer, the following example illustrates the method. The system task exception handling method provided in this disclosure may include the following steps: 1. Retrieve metadata state variables: When the task execution reaches the point where a process selection decision needs to be made, obtain metadata status variables, including: The first status variable is used to identify whether the metadata repair process is in progress.

[0045] The second state variable is used to indicate that the metadata repair process has been completed and verified.

[0046] 2. Determine whether the metadata status variables meet the preset abnormal state conditions: Check if the first status variable indicates that the repair process is in progress; Check if the second status variable indicates that the repair operation was not completed or the verification failed.

[0047] If both conditions are met, the metadata state variable satisfies the preset abnormal state conditions.

[0048] 3. Implement the first decision: If the metadata status variables meet the preset abnormal status conditions, then the task exit operation is executed, which may include recording the abnormal status information to the log file, sending an alarm notification to the system administrator, terminating the current repair task, etc.

[0049] It can also enter a delayed retry state: remove the current task from the execution queue; and retry execution after a preset time. For example, set a preset delay time (such as 5 minutes) (preset duration), and after the delay time expires, add the task back to the execution queue and try to execute it again.

[0050] 4. Implement the second decision: If the metadata status variables do not meet the preset abnormal status conditions, the system can check whether the first status variable indicates that the repair process is in progress, and whether the second status variable indicates that the repair operation has been completed and verified. If the first status variable indicates that the repair process is in progress and the second status variable indicates that the repair operation has been verified, the current task continues to execute. Alternatively, if the first status variable indicates that there is no ongoing repair process, the current task continues to execute.

[0051] To make the system task exception handling method provided in this disclosure embodiment clearer, the following is combined with Figure 3 and Figure 4 This will be illustrated with examples. Figure 3 and Figure 4The system task exception handling method provided in this disclosure embodiment may include the following processing: 1. Define two-state variables, also known as metadata state variables, which may include: Two state variables (i.e. metadata state variables) are defined in the system's global memory: Variable A (wait_bm) (i.e., the first state variable): indicates whether the metadata repair process has been officially started and is being executed; Variable B (finish_bm) (i.e., the second state variable): indicates whether the core repair operation in the metadata repair process has been completed and verified. This variable is false when the repair process starts, and is only set to true after the repair operation is successfully executed and verified.

[0052] 2. Modify the decision logic in the task callback function, specifically as follows: The callback function or key decision point processing logic for the block space balancing task is modified as follows: First, when the task reaches a decision point requiring process selection, the system synchronously queries the current values ​​of the first and second state variables mentioned above. Then, based on different combinations of these two state variable values, differentiated decision paths are executed, specifically including: First, when the first state variable indicates that the repair process is in progress and the second state variable indicates that verification has not yet passed: this combined state indicates that the system is in a critical and most unstable period of the repair operation. At this time, the system will control the background task to immediately execute a series of safe exit operations. These operations include, but are not limited to, releasing all locks, memory buffers, and other critical system resources currently held by the task. Subsequently, the task itself enters a delayed retry state, that is, it actively exits the execution queue and is scheduled to retry execution after a predetermined period of time. The core purpose of this path is to actively release resource occupation and completely avoid resource contention or circular waiting with high-priority repair processes.

[0053] Second, when the first status variable indicates that the repair process is in progress and the second status variable indicates that the verification has passed: this combined status indicates that the core operation of metadata repair has been successfully completed and the system state has returned to stability. At this time, the system will determine that the current environment is safe and control the background tasks to continue their normal execution process without any interruption or intervention.

[0054] Third, when the first status variable indicates that no repair process is in progress: this status indicates that the system is completely normal and no metadata failure has occurred. At this time, the system also controls the background tasks to continue their normal execution process.

[0055] 3. In the code of the metadata repair process, these two state variables need to be updated precisely at key nodes, as follows: At the start of the process, wait_bm = TRUE and finish_bm = FALSE can be set. After the core repair operation is completed and verified, finish_bm = TRUE can be set. When the entire process is completely finished, wait_bm = FALSE can be reset. Through the above implementation method, the system can clearly distinguish between the two states of "repairing - unstable" and "repair completed - stable", thereby making distinct but correct decisions for background tasks and fundamentally avoiding deadlock.

[0056] Based on this, the system task exception handling method provided in this embodiment can maintain two metadata state variables (i.e., a first state variable indicating whether the metadata repair process is in progress, and a second state variable indicating that the repair operation of the metadata repair process has been completed and verified), respectively indicating whether the fault repair process is in progress and whether its core operation has been completed and verified; when the background task reaches the decision point, the current values ​​of the two metadata state variables can be queried synchronously; based on the combination result of the values ​​of the two metadata state variables, the background task can be controlled to execute different operation decision branches (e.g., the first decision and the second decision); if the repair process is in progress but the verification fails, the background task can be controlled to immediately release all occupied resources and can enter a delayed retry state; if the repair process is in progress and the verification has passed, the background task can be controlled to continue to execute the process normally; at different execution stages of the fault repair process, the variable values ​​of the above two metadata state variables can also be updated.

[0057] In this way, a simple state machine model can be constructed using two intrinsically related metadata state variables (i.e., a first state variable indicating whether the metadata repair process is in progress, and a second state variable indicating that the repair operation of the metadata repair process has been completed and verified) to replace a single Boolean flag. This enables the phase division of the repair process and the fine-grained management of abnormal system states, thereby providing a clear and secure decision-making basis for complex process collaboration within a centralized system. Furthermore, diversified decisions can be made based on the combination of the two metadata state variables (rather than the true or false of a single state flag), such as continuing execution, releasing resources and exiting, or delaying retrying, to achieve fine-grained control of decision logic. Moreover, by proactively and forcibly releasing resources during the most critical unstable periods of the system, the generation of circular waiting conditions can be prevented from the design stage, thereby solving the deadlock problem caused by tight coupling in centralized systems.

[0058] It should be noted that the embodiments of this disclosure may include multiple steps. For ease of description, these steps are numbered, but these numbers are not a limitation on the execution time slots or execution order between the steps; these steps can be implemented in any order, and the embodiments of this disclosure do not limit this.

[0059] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0060] According to embodiments of this disclosure, this disclosure also provides a system task exception handling apparatus.

[0061] For example, Figure 5 This is a schematic diagram of a system task exception handling device provided in an embodiment of the present disclosure. The system task exception handling device 500 includes: The acquisition module 510 is used to acquire metadata status variables; wherein, the status variables include a first status variable that indicates whether the metadata repair process is being executed, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified. The determination module 520 is used to determine whether the metadata status variables meet the preset abnormal status conditions; wherein, the preset abnormal status conditions include at least one of the following: the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation is not completed or the verification has failed; The execution module 530 is used to execute the first decision when the metadata state variables meet the preset abnormal state conditions.

[0062] Furthermore, execution module 530 is used for: If the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has not been completed or the verification has failed, a task exit operation is performed; wherein, the task exit operation includes releasing at least one of all locks, memory buffers, and system resources currently held by the current task.

[0063] Furthermore, execution module 530 is also used for: If the metadata state variables do not meet the preset abnormal state conditions, a second decision is executed; the second decision includes continuing to execute the current task.

[0064] Furthermore, execution module 530 is used for: If the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has been verified, then the second decision is executed.

[0065] Furthermore, execution module 530 is used for: If the first state variable indicates that there is no ongoing repair process, then execute the second decision.

[0066] Furthermore, module 510 is used for: When the task execution reaches the point where a process selection decision needs to be made, the metadata status variables are obtained.

[0067] Furthermore, it also includes a retry module for: The current task has entered a delayed retry state; the delayed retry state includes exiting the execution queue and retrying execution after a preset time.

[0068] Furthermore, it also includes an adjustment module for: Obtain the priority of the current task; The preset duration is adjusted based on the priority of the current task.

[0069] Furthermore, the adjustment module is also used for: Obtain historical retry data of the current task within a preset time period; wherein, the historical retry data includes the number of retries and the preset duration; If the number of retries exceeds a preset threshold, the retry strategy is adjusted; wherein, the adjusted retry strategy includes at least one of the following: Adjust the retry method for the current task; Adjust the preset duration.

[0070] It should be noted that the description of the features in the corresponding embodiments of the device can be found in the relevant description of the corresponding embodiments of the method, and will not be repeated here.

[0071] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0072] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.

[0073] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0074] Embodiments of this disclosure also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0075] Embodiments of this disclosure also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

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

[0077] The above provides a detailed description of a system task exception handling method provided by this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this disclosure without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this disclosure.

Claims

1. A method for handling system task exceptions, characterized in that, include: Obtain metadata status variables; among which, the status variables include a first status variable that indicates whether the metadata repair process is in progress, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified. Determine whether the metadata status variable meets the preset abnormal status conditions; wherein, the preset abnormal status conditions include at least one of the following: the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation is not completed or the verification has failed; If the metadata state variable satisfies the preset abnormal state condition, the first decision is executed.

2. The method according to claim 1, characterized in that, When the metadata state variable satisfies the preset abnormal state condition, the first decision is executed, including: If the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has not been completed or the verification has failed, a task exit operation is performed; wherein, the task exit operation includes releasing at least one of all locks, memory buffers, and system resources currently held by the current task.

3. The method according to claim 1, characterized in that, After determining whether the metadata state variable meets the preset abnormal state conditions, the method further includes: If the metadata state variable does not meet the preset abnormal state condition, a second decision is executed; wherein, the second decision includes continuing to execute the current task.

4. The method according to claim 3, characterized in that, When the metadata state variable does not meet the preset abnormal state condition, the second decision is executed, including: The second decision is executed when the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has been verified.

5. The method according to claim 3, characterized in that, When the metadata state variable does not meet the preset abnormal state condition, the second decision is executed, including: If the first state variable indicates that there is no ongoing repair process, the second decision is executed.

6. The method according to claim 1, characterized in that, The acquisition of metadata status variables includes: When the task execution reaches the point where a process selection decision needs to be made, the metadata status variables are obtained.

7. The method according to claim 1 or 2, characterized in that, After executing the first decision when the metadata state variable satisfies the preset abnormal state condition, the process further includes: The current task has entered a delayed retry state; wherein, the delayed retry state includes exiting the execution queue and retrying execution after a preset time.

8. The method according to claim 7, characterized in that, After the current task enters the delayed retry state, it also includes: Obtain the priority of the current task; The preset duration is adjusted based on the priority of the current task.

9. The method according to claim 7, characterized in that, After the current task enters the delayed retry state, it also includes: Obtain historical retry data of the current task within a preset time period; wherein, the historical retry data includes the number of retries and the preset duration; If the number of retries exceeds a preset threshold, the retry strategy is adjusted; wherein, the adjusted retry strategy includes at least one of the following: Adjust the retry method for the current task; Adjust the preset duration.

10. 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 that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-9.

Images