A request task processing method and device

Abstract

The application discloses a request task processing method and device, and relates to the technical field of application development. A specific embodiment of the application comprises: in response to a request task in a page being submitted, storing request basis data of the request task into a persistent storage and storing request running data into a memory of a request execution unit; in response to the page being restarted, determining that there is a left request task in the request task, obtaining request basis data corresponding to the left request task from the persistent storage; based on a current running context, reconstructing target running data of the left request task, and using the request execution unit to re-execute the left request task based on the request basis data and the target running data of the left request task. The embodiment of the application overcomes the problems of low fault tolerance and data loss caused by processing a left request task based on complete request data in the prior art, and improves user experience.

Description

Technical Field

[0001] This invention relates to the field of application development technology, and in particular to a request task processing method and apparatus. Background Technology

[0002] In application page business processing, there are usually scenarios that include submitting business requests, such as submitting forms, uploading files, and retrieving data. In actual scenarios, when submitting business requests, there may be situations where the submission is not completed due to network reasons, and the user closes or refreshes the page at the same time.

[0003] Existing methods typically store the complete request data when the business request is submitted, and then attempt to resend the business request based on the complete request data after the page is restarted. However, existing methods cannot handle various situations such as changes in web page address, expired business requests, and excessive resending, resulting in low fault tolerance and potential data loss, which seriously affects the user experience. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a request task processing method and apparatus. In response to a request task being submitted on a page, the basic request data of the request task is stored in persistent storage, and the request execution data is stored in the memory of a request execution unit. In response to restarting the page, if a legacy request task is determined to exist, the basic request data corresponding to the legacy request task is retrieved from persistent storage. The target execution data of the legacy request task is reconstructed based on the current execution context. Using the request execution unit, the legacy request task is re-executed based on the basic request data and the target execution data. Embodiments of the present invention overcome the problems of low fault tolerance and data loss caused by processing legacy request tasks based on complete request data in existing methods, thereby improving the user experience.

[0005] To achieve the above objectives, according to one aspect of the present invention, a request task processing method is provided, comprising: in response to one or more request tasks being submitted on a page, obtaining request data of the request tasks, storing the request base data contained in the request data in persistent storage, and storing the request execution data contained in the request data in the memory of a request execution unit; in response to restarting the page, determining that there are legacy request tasks among the request tasks, obtaining the request base data corresponding to the legacy request tasks from the persistent storage; obtaining the current running context, reconstructing the target execution data of the legacy request tasks based on the current running context, and storing the target execution data in the memory of the request execution unit; and using the request execution unit, re-executing the legacy request tasks based on the request base data and the target execution data of the legacy request tasks.

[0006] Optionally, before obtaining the current running context and reconstructing the target running data of the legacy request task based on the request running data and the current running context, the method further includes: obtaining the request creation time from the request base data of the legacy request task; determining the interval between the current time and the request creation time; and if it is determined that the interval exceeds the valid duration, sending a clear message about clearing the legacy request task to perform the operation of clearing the legacy request task.

[0007] Optionally, the running status of the request execution unit is monitored, and the running status includes any one of: success, retry, failure, error, and custom exception; a status notification message containing the running status is sent.

[0008] Optionally, obtaining the current running context and reconstructing the target running data of the legacy request task based on the request running data and the current running context further includes: monitoring the construction result of reconstructing the target running data of the legacy request task; if the construction result is determined to be a construction failure, sending a clear message about clearing the legacy request task to perform the operation of clearing the legacy request task.

[0009] Optionally, if the construction result is determined to be successful, the number of retries and the maximum allowed number of retries of the legacy request task are obtained from the request base data of the legacy request task; the number of retries that can be retried for the legacy request task is calculated based on the number of retries and the maximum allowed number of retries; and the legacy request task is re-executed based on the number of retries.

[0010] Optionally, calculating the retry count of the legacy request task based on the number of retries already attempted and the maximum allowed number of retries includes: calculating half of the maximum allowed number of retries; if the number of retries already attempted is not less than half of the value, using the half of the value as the retry count of the legacy request task; if the number of retries already attempted is less than half of the value, using the difference between the maximum allowed number of retries and the number of retries already attempted as the retry count of the legacy request task.

[0011] Optionally, in response to restarting the page, or in response to the request execution unit performing a destruction operation, the data stored in the memory of the request execution unit is automatically cleared.

[0012] To achieve the above objectives, according to a second aspect of the present invention, a request task processing apparatus is provided, comprising: a data storage module, a data reconstruction module, and a request retransmission module; wherein, The data storage module is used to respond to the submission of one or more request tasks on the page, obtain the request data of the request task, store the request base data contained in the request data in persistent storage, and store the request execution data contained in the request data in the memory of the request execution unit. The data reconstruction module is used to respond to page restart, determine that there is a legacy request task in the request task, obtain the request basic data corresponding to the legacy request task from the persistent storage; obtain the current running context, reconstruct the target running data of the legacy request task based on the current running context, and store the target running data in the memory of the request execution unit; The resend request module is used to re-execute the legacy request task based on the request base data and the target running data of the legacy request task using the request execution unit.

[0013] Optionally, the request task processing apparatus is configured to, before obtaining the current running context and reconstructing the target running data of the legacy request task based on the request running data and the current running context, further include: obtaining the request creation time from the request base data of the legacy request task; determining the interval between the current time and the request creation time; and, if it is determined that the interval exceeds the valid duration, sending a clear message regarding clearing the legacy request task to perform the operation of clearing the legacy request task.

[0014] Optionally, the request task processing device is configured to monitor the running status of the request execution unit, the running status including any one of: success, retry, failure, error, and custom exception; and send a status notification message containing the running status.

[0015] Optionally, the request task processing device is configured to obtain the current running context, and reconstruct the target running data of the legacy request task based on the request running data and the current running context, further comprising: monitoring the construction result of reconstructing the target running data of the legacy request task; and, if the construction result is determined to be a construction failure, sending a clear message regarding clearing the legacy request task to perform the operation of clearing the legacy request task.

[0016] Optionally, the request task processing device is configured to, when determining that the construction result is successful, obtain the number of retries and the maximum allowed number of retries of the legacy request task from the request base data of the legacy request task; calculate the number of retries for the legacy request task based on the number of retries and the maximum allowed number of retries; and re-execute the legacy request task based on the number of retries.

[0017] Optionally, the request task processing device is configured to calculate the retry count of the legacy request task based on the number of retries already attempted and the maximum allowed number of retries, including: calculating half of the maximum allowed number of retries; if it is determined that the number of retries already attempted is not less than half of the value, using the half of the value as the retry count of the legacy request task; if it is determined that the number of retries already attempted is less than half of the value, using the difference between the maximum allowed number of retries and the number of retries already attempted as the retry count of the legacy request task.

[0018] Optionally, the request task processing device is configured to automatically clear the data stored in the memory of the request execution unit in response to restarting the page, or in response to the request execution unit performing a destruction operation.

[0019] To achieve the above objectives, according to a third aspect of the present invention, an electronic device for request task processing is provided, characterized in that it includes: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform any of the methods described above for request task processing.

[0020] To achieve the above objectives, according to a fourth aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, characterized in that, when the program is executed by a processor, it implements the method described in any of the above-described request task processing methods.

[0021] To achieve the above objectives, according to a fifth aspect of the present invention, a computer program product is provided, comprising a computer program, characterized in that, when executed by a processor, the computer program implements any of the methods described above for request task processing.

[0022] One embodiment of the above invention has the following advantages or beneficial effects: In response to a request task being submitted on a page, the request base data of the request task is stored in persistent storage, and the request execution data is stored in the memory of the request execution unit; in response to restarting the page, it is determined that there is a legacy request task among the request tasks, and the request base data corresponding to the legacy request task is retrieved from persistent storage; the target execution data of the legacy request task is reconstructed based on the current running context, and the legacy request task is re-executed using the request execution unit based on the request base data and the target execution data of the legacy request task. This embodiment of the invention overcomes the problems of low fault tolerance and data loss caused by processing legacy request tasks based on complete request data in existing methods, thus improving the user experience.

[0023] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0024] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein: Figure 1 This is a flowchart illustrating a request task processing method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a request task processing flow provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a request task processing method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a request task processing device provided in an embodiment of the present invention; Figure 5 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied; Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0025] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details 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 the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0026] It should be noted that the collection, use, storage, sharing and transfer of user personal information involved in the technical solution of the present invention all comply with the provisions of relevant laws and regulations, and require notification to users and obtaining their consent or authorization. When applicable, user personal information is subjected to de-identification and / or anonymization and / or encryption technical processing.

[0027] Existing methods cannot effectively handle various scenarios that occur during page restarts, such as changes in webpage addresses, expired business requests, and excessive resending, resulting in low fault tolerance and data loss. For example, in scenarios where webpage addresses change, the URLs (Uniform Resource Locators) in the test and production environments differ. If the URL retained from before the restart is used after the page restarts, request data will be sent to the incorrect environment, causing test and production data to interfere with each other. The lack of error messages leads users to believe the data has been successfully submitted. Existing methods also fail to handle expired business requests and excessive resending, and do not send error messages, making it impossible for users to track the status of legacy request tasks.

[0028] In view of this, such as Figure 1 As shown, this embodiment of the invention provides a request task processing method, which may include the following steps: Step S101: In response to the submission of one or more request tasks on the page, obtain the request data of the request task, store the request base data contained in the request data in persistent storage, and store the request execution data contained in the request data in the memory of the request execution unit.

[0029] Step S102: In response to restarting the page, determine that there is a legacy request task in the request task, obtain the request basic data corresponding to the legacy request task from the persistent storage; obtain the current running context, reconstruct the target running data of the legacy request task based on the current running context, and store the target running data in the memory of the request execution unit.

[0030] Step S103: Using the request execution unit, the legacy request task is re-executed based on the request base data and the target running data of the legacy request task.

[0031] Specifically, embodiments of the present invention utilize various methods to handle legacy page request tasks after page restart (e.g., closing, non-first launch, refresh, etc.), thereby improving the fault tolerance and reliability of page request task processing and enhancing the user experience.

[0032] In this embodiment of the invention, after the page is launched, one or more request tasks related to the page can be added to the task queue. For each request task, the request data of the request task is divided into two types (request basic data and request execution data) and stored separately. Specifically, the request basic data contained in the request data is stored in persistent storage, and the request execution data contained in the request data is stored in the memory of the request execution unit.

[0033] The basic request data stored in persistent storage includes, for example: id (request identifier), createdAt (creation timestamp), ossPath or ossFileName (request parameters), data (business request body data), interfacePath (interface path used for alarms), retryCount (number of retries), maxRetry (maximum number of retries), lastError (last error message), etc.; persistent storage is a data source such as IndexedDB, where IndexedDB is a browser-built-in client-side NoSQL database that supports transactions, indexes, and persistence of large amounts of data.

[0034] The request execution data stored in the memory of the request execution unit includes, for example, requestUrl (request address), method (request method, such as Get, Post, Delete, etc.), headers (request header data), Authorization (authentication information), timeoutMs (timeout period), etc.; among which, request execution data can be sent to the memory of the request execution unit via postMessage.

[0035] In this embodiment of the invention, the request base data is data independent of the runtime environment, while the request execution data is directly related to the runtime environment and is therefore stored only in the memory of the request execution unit. For example, the request execution unit is a WebWorker, which can be an independent thread running in the background to handle request tasks, and it interacts with the main page thread through messages.

[0036] Furthermore, the request execution unit can maintain a MAP data structure TASK_CONFIG_MAP stored in memory, represented as: TASK_CONFIG_MAP: Map<taskId, WorkerConfig> Here, taskID represents the request task identifier, and WorkerConfig represents the request execution data.

[0037] Furthermore, the data stored in the memory of the request execution unit is dynamic data and is cleared when the page is restarted or the instance of the request execution unit is destroyed. That is, in response to restarting the page, or in response to the request execution unit performing a destruction operation, the data stored in the memory of the request execution unit is automatically cleared.

[0038] By dividing the request data of the request task into two types and storing them separately, the environment-related runtime data can be reconstructed after the page is restarted. This overcomes the problem of legacy tasks using the wrong domain name or token (such as authorization information, timeout time, etc.) when switching between multiple environments in existing methods.

[0039] Furthermore, upon page restart, the system can retrieve data such as basic request data and the page's corresponding task queue to determine whether requests made before the page restart were completed (or executed successfully). If a request was not completed or executed successfully, it is marked as a legacy request task. This confirms the existence of legacy request tasks, which represent requests processed by the page before the restart that were not completed. Examples include sending a request but receiving no feedback, or uploading a file but not receiving a message indicating successful upload.

[0040] After determining that there are legacy request tasks, different methods are used for fault tolerance processing in this embodiment of the invention: The first method is to obtain the request creation time from the request base data of the legacy request task; determine the interval between the current time and the request creation time; and if it is determined that the interval exceeds the valid duration, send a clear message to clear the legacy request task to perform the operation of clearing the legacy request task.

[0041] Specifically, the validity period of the request is TTL (Time To Live). The storage period of the legacy request task can be determined based on the current time and the creation time of the legacy request task. If it exceeds the TTL, a clear message about clearing the legacy request task can be sent directly to the thread or module that performs the clearing to perform the clearing operation. Alternatively, a prompt message containing the clearing task can be reported to the listening module so that the listening module can perform further operations based on the obtained status of the legacy request task.

[0042] The second method involves: obtaining the request base data corresponding to the legacy request task from the persistent storage; obtaining the current running context; reconstructing the target running data of the legacy request task based on the current running context; storing the target running data in the memory of the request execution unit; and using the request execution unit to re-execute the legacy request task based on the request base data and the target running data.

[0043] Specifically, the method for triggering the reconstruction of the target runtime data of the legacy request task is as follows: receive the ResumeConfigProvider functional parameter passed in by the caller, use the function (ResumeConfigProvider) to receive the legacy request task object, recalculate and return the legacy task object WorkerConfig (i.e., the target runtime data) according to the current page environment (i.e., the current runtime context), where the current runtime context is data such as requestUrl, method, headers, Authorization, and timeoutMs that are directly related to the environment.

[0044] Furthermore, the reconstructed target runtime data is stored in the memory of the request execution unit, so that the request execution unit can re-execute the legacy request task based on the request base data of the legacy request task and the target runtime data.

[0045] Understandably, by dynamically constructing new target runtime data, the problems of existing methods using request data before page restart, resulting in unsuccessful requests and data loss due to address changes, expired runtime data, etc., are overcome.

[0046] The third method is to monitor the construction result of the target running data of the task to rebuild the legacy request; if the construction result is determined to be a failure, a clear message is sent to clear the legacy request task.

[0047] Specifically, during the process of reconstructing the target runtime data of the legacy request task, the construction result of the reconstructed target runtime data of the legacy request task is monitored. If the construction result is a failure, such as the provider returning null or being unable to rebuild, a clear message is sent to clear the legacy request task, and the operation of eliminating the legacy request task is performed, that is, the subsequent re-execution of the legacy request task is not performed.

[0048] The fourth method: If the construction result is determined to be successful, obtain the number of retries and the maximum allowed number of retries of the legacy request task from the request base data of the legacy request task; calculate the number of retries of the legacy request task based on the number of retries and the maximum allowed number of retries; and re-execute the legacy request task based on the number of retries.

[0049] Specifically, the existing retry handling strategy is to reset the number of retryable attempts to the maximum allowed number of retry attempts, or to directly use the difference between the maximum allowed number of retry attempts and the number of retry attempts as the number of retryable attempts.

[0050] The existing methods have the following problems: Resetting retryCount will cause errors in the business layer (such as incorrect parameters, quota exceeding limits, or files already existing) to be retried N times (the maximum allowed number of retries) every time the page is refreshed. This will result in requests with identical parameters being executed repeatedly, which may lead to duplicate data being written to the database.

[0051] Using the difference between the maximum allowed number of retries and the number of retries already completed might cause a task that is only one retries away from being completed to be immediately judged as having "reached the maximum number of retries" and discarded when the page is restarted, thus losing a reasonable opportunity to resume the download.

[0052] To overcome the problems of existing methods regarding retry strategies, this embodiment of the invention adopts the following method for calculating the number of retry attempts: if the construction result is determined to be successful, the number of retry attempts (retryCount) and the maximum allowed number of retry attempts (maxRetry) of the legacy request task are obtained from the request base data of the legacy request task. Based on the number of retry attempts, the legacy request task is re-executed.

[0053] Specifically, calculating the retry count of the legacy request task based on the number of retries already made and the maximum allowed number of retries includes: calculating half of the maximum allowed number of retries; if the number of retries already made is not less than half of the value, using the half of the value as the retry count of the legacy request task; if the number of retries already made is less than half of the value, using the difference between the maximum allowed number of retries and the number of retries already made as the retry count of the legacy request task.

[0054] According to the retry strategy adopted in this embodiment of the invention, if the legacy request task has been retried ≥ maxRetry / 2 times on the page before restart, it indicates that the request task is highly likely to be an unretrieable error of the business layer itself (e.g., incorrect parameters, file already existing, etc.). Therefore, the restarted page is set to a maximum of maxRetry / 2 retries to overcome the problem of duplicate data storage. If the legacy request task has been retried less than maxRetry / 2, the difference between the maximum allowed retries and the already retried count is taken as the retry count for the legacy request task. Here, maxRetry / 2 is half of the maximum allowed retries. Calculating the retry count improves the rationality and fault tolerance of retries.

[0055] The following is an illustration of how to calculate the number of retries: resumeBudget = floor(maxRetry / 2) if (task.retryCount > resumeBudget) { task.retryCount = resumeBudget;… / / Otherwise, retain the original retryCount.

[0056] Preferably, the running status of the request execution unit is monitored, and the running status includes any one of: success, retry, failure, error, and custom exception; a status notification message containing the running status is sent. Specifically, a preset monitoring module is used to monitor the execution status of each step or component after the page restarts. For example, the running status of the request execution unit includes success, failure, error, retry, etc. The main thread of the page can monitor and capture the running status of the request execution unit (e.g., global exceptions) through the following hooks: worker.addEventListener('error') and

[0057] `self.addEventListener('unhandledrejection')` is used to overcome situations where the request execution unit encounters an exception but the exception status is not detected.

[0058] In this embodiment of the invention, the following data are monitored and acquired: the running status of the request execution unit (success, retry, failure, error, custom exception, etc.), TTL expiration status, and the construction result of the target running data of the reconstructed legacy request task, and sent to the front end (e.g., the caller), thereby improving the real-time performance and efficiency of legacy request task processing in the specific scenario of "front end + multiple environments + cross refresh + business request level".

[0059] In this embodiment of the invention, a unified WorkerMessage channel can be set up to distribute messages as shown in Table 1 to the listening module via UploadQueueManager.emit(), enabling the listening module to obtain various statuses of legacy request tasks in real time. This overcomes the problem in existing methods that can only obtain the running status or failure of the request unit, and cannot obtain all statuses.

[0060] Table 1

[0061] like Figure 2 As shown, this embodiment of the invention provides a request task processing flow, which may include the following steps: Step S201: In response to restarting the page, determine whether there are any legacy request tasks on the page. If so, proceed to step S202; otherwise, end the current process.

[0062] Step S202: Determine the interval duration for legacy request tasks.

[0063] Step S203: Determine whether the interval duration exceeds the valid duration. If yes, proceed to step S205; otherwise, proceed to step S204.

[0064] Step S204: Reconstruct the target runtime data for the legacy request task.

[0065] Step S205: Send a cleanup message and clear legacy request tasks.

[0066] Step S206: Determine whether the construction result of the target running data of the reconstructed legacy request task is successful. If yes, proceed to step S207; otherwise, proceed to step S205.

[0067] Step S207: Calculate the number of times the legacy request task can be retried based on the number of retries already made and the maximum allowed number of retries.

[0068] Step S208: Based on the number of retry attempts, re-execute the legacy request task.

[0069] The specific descriptions of steps S201 to S208 are consistent with those of steps S101 to S103, and will not be repeated here.

[0070] like Figure 3 As shown, this embodiment of the invention provides a structure for a request task processing method, including: a main thread 301, a data reconstruction module 302, a listening module 303, a persistent storage layer 304, and a request execution unit 305; wherein, The main thread 301 is used to respond to one or more request tasks being submitted on the page, obtain the request data of the request task, store the request basic data contained in the request data in persistent storage 304, and store the request running data contained in the request data in the memory of the request execution unit; in response to restarting the page, if it is determined that there are legacy request tasks among the request tasks, the request basic data corresponding to the legacy request task is obtained from the persistent storage.

[0071] The main thread 301 is also used to monitor the running status of the request execution unit, determine the interval between the current time and the request creation time, and monitor the construction result of the target running data of the reconstructed legacy request task.

[0072] The rebuild runtime data module 302 is used to obtain the current runtime context, reconstruct the target runtime data of the legacy request task based on the current runtime context, and store the target runtime data in the memory of the request execution unit.

[0073] Listening module 303 is used to obtain various states related to handling legacy request tasks from the main thread (as shown in Table 1).

[0074] The request execution unit 305 is used to re-execute the legacy request task based on the request base data and the target running data of the legacy request task.

[0075] The embodiments of the present invention improve the efficiency, state awareness, and maintainability of handling legacy request tasks through the interaction and communication between different components.

[0076] like Figure 4 As shown, this embodiment of the invention provides a request task processing device 400, including: a data storage module 401, a data reconstruction module 402, and a request retransmission module 403; wherein, The data storage module 401 is used to respond to the submission of one or more request tasks on the page, obtain the request data of the request task, store the request basic data contained in the request data in persistent storage, and store the request running data contained in the request data in the memory of the request execution unit. The data reconstruction module 402 is used to respond to the page restart, determine that there is a legacy request task in the request task, obtain the request basic data corresponding to the legacy request task from the persistent storage; obtain the current running context, reconstruct the target running data of the legacy request task based on the current running context, and store the target running data in the memory of the request execution unit; The resend request module 403 is used to re-execute the legacy request task based on the request base data and the target running data of the legacy request task using the request execution unit.

[0077] This invention also provides an electronic device for request task processing, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method provided in any of the above embodiments.

[0078] This invention also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method provided in any of the above embodiments.

[0079] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements any of the methods described above for request task processing.

[0080] Figure 5An exemplary system architecture 500 is shown that can be applied to the request task processing method or request task processing apparatus of the present invention.

[0081] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, and 503, a network 504, and a server 505. Network 504 serves as the medium for providing communication links between terminal devices 501, 502, and 503 and server 505. Network 504 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0082] Users can use terminal devices 501, 502, and 503 to interact with server 505 via network 504 to receive or send messages, etc. Various client applications can be installed on terminal devices 501, 502, and 503, such as e-commerce client applications, web browser applications, search applications, instant messaging tools, and email clients.

[0083] Terminal devices 501, 502, and 503 can be various electronic devices with displays and supporting various client applications, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0084] Server 505 can be a server that provides various services, such as a backend management server that supports client applications used by users through terminal devices 501, 502, and 503. The backend management server can process received page data retrieval requests and return the basic request data to the terminal devices.

[0085] It should be noted that the request task processing method provided in the embodiments of the present invention is generally executed by terminal devices 501, 502, and 503, and correspondingly, the request task processing device is generally disposed in terminal devices 501, 502, and 503.

[0086] It should be understood that Figure 5 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0087] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing a terminal device of the present invention. Figure 6 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0088] like Figure 6As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0089] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0090] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined above in the system of this invention.

[0091] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] The modules and / or units described in the embodiments of the present invention can be implemented in software or hardware. The described modules and / or units can also be located in a processor. For example, a processor can be described as including a data storage module, a data reconstruction module, and a request retransmission module. The names of these modules do not necessarily limit the module itself; for example, the data storage module can also be described as "a module that stores request base data in persistent storage and stores request execution data in the memory of the request execution unit."

[0094] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: in response to a request task being submitted on a page, storing the request base data of the request task in persistent storage and storing the request execution data in the memory of a request execution unit; in response to restarting the page, determining that there is a legacy request task among the request tasks, retrieving the request base data corresponding to the legacy request task from persistent storage; reconstructing the target execution data of the legacy request task based on the current execution context, and re-executing the legacy request task using the request execution unit based on the request base data and the target execution data of the legacy request task. The embodiments of the present invention overcome the problems of low fault tolerance and data loss caused by processing legacy request tasks based on complete request data in existing methods, thus improving the user experience.

[0095] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A request task processing method, characterized in that, include: In response to the submission of one or more request tasks on the page, the request data of the request task is obtained, the request base data contained in the request data is stored in persistent storage, and the request execution data contained in the request data is stored in the memory of the request execution unit. In response to restarting the page, it is determined that there is a legacy request task in the request task. The request basic data corresponding to the legacy request task is obtained from the persistent storage; the current running context is obtained, the target running data of the legacy request task is reconstructed based on the current running context, and the target running data is stored in the memory of the request execution unit. Using the request execution unit, the legacy request task is re-executed based on the request base data and the target running data of the legacy request task.

2. The method according to claim 1, characterized in that, Before obtaining the current running context and reconstructing the target running data of the legacy request task based on the request running data and the current running context, the process further includes: Obtain the request creation time from the request base data of the legacy request task; Determine the duration of the interval between the current time and the time the request was created; If it is determined that the interval duration exceeds the valid duration, a clear message is sent to clear the legacy request task, so as to perform the operation of clearing the legacy request task.

3. The method according to claim 1, characterized in that, Further includes: Monitor the running status of the request execution unit, the running status including any one of: success, retry, failure, error, and custom exception; Send a status notification message containing the running status.

4. The method according to claim 1, characterized in that, The step of obtaining the current running context and reconstructing the target running data of the legacy request task based on the request running data and the current running context further includes: Monitor the construction results of the target runtime data of the task to rebuild the legacy request; If the construction result is determined to be a construction failure, a clear message is sent to clear the legacy request task in order to perform the operation of clearing the legacy request task.

5. The method according to claim 4, characterized in that, Further includes: If the construction result is determined to be successful... Obtain the number of retries and the maximum allowed number of retries for the legacy request task from the request base data of the legacy request task; The number of times the legacy request task can be retried is calculated based on the number of retries already completed and the maximum allowed number of retries. Based on the number of retry attempts, the legacy request task is re-executed.

6. The method according to claim 5, characterized in that, The step of calculating the retryable number of the legacy request task based on the number of retries already attempted and the maximum allowed number of retries includes: Calculate half of the maximum allowed number of retries; If it is determined that the number of retries is not less than half of the value, then the half value is taken as the number of retries for the legacy request task; If the number of retries is determined to be less than half of the given value, the difference between the maximum allowed number of retries and the number of retries is taken as the number of retries that the legacy request task can be retried.

7. The method according to claim 1, characterized in that, Further includes: In response to restarting the page, or in response to the request execution unit performing a destruction operation, the data stored in the memory of the request execution unit is automatically cleared.

8. A request task processing apparatus, characterized in that, include: The module consists of a data storage module, a data reconstruction module, and a resend request module; among which, The data storage module is used to respond to the submission of one or more request tasks on the page, obtain the request data of the request task, store the request base data contained in the request data in persistent storage, and store the request execution data contained in the request data in the memory of the request execution unit. The data reconstruction module is used to respond to page restart, determine that there is a legacy request task in the request task, obtain the request basic data corresponding to the legacy request task from the persistent storage; obtain the current running context, reconstruct the target running data of the legacy request task based on the current running context, and store the target running data in the memory of the request execution unit; The resend request module is used to re-execute the legacy request task based on the request base data and the target running data of the legacy request task using the request execution unit.

9. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

11. A computer program product, comprising a computer program, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

Images