Request processing method, system and equipment for application program and medium

Abstract

The invention relates to the technical field of computer software, in particular to a request processing method, system and equipment for an application program and a medium. The method is applied to a client, the client is connected with a server through a network, and the method comprises the following steps: acquiring request information, generating and initiating an original request according to the request information, and recording an original timestamp of the original request; obtaining a response state of the original request, and if the response state is response failure, judging whether the request information meets a preset retry requirement or not; if yes, obtaining the remaining time length based on the current moment and the original timestamp, and judging whether the remaining time length exceeds a preset time length threshold value or not; if yes, applying for obtaining a reentrant lock, and when the reentrant lock is obtained, modifying an original tag head of the original request into a retry tag head to generate a retry request; and initiating a retry request, asynchronously processing the retry request, obtaining a request result, counting the request result into a log, and releasing the relockable lock. According to the invention, the problems of system resource exhaustion and server crash can be prevented.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software, and particularly relates to a request processing method, system, device and medium of an application program. BACKGROUND

[0002] A network request refers to a process in which a client sends an instruction to a server to obtain a resource or perform an operation. When a network request fails, a retry operation is usually performed immediately without considering the occupation of system resources and the actual state of the network. Some schemes limit the number of retries by using a simple counter, or set a fixed retry interval, and some schemes use an exponential backoff algorithm to gradually increase the retry interval time.

[0003] When multiple requests fail at the same time, the traditional retry scheme can cause a large number of retry requests to be initiated at the same time, thereby forming a "retry storm". A large number of retry requests can simultaneously flow into the server, causing the server load to increase sharply, and even causing the server to crash. SUMMARY

[0004] Embodiments of the present application provide a request processing method, system, electronic device and storage medium to solve the problem that when multiple requests fail at the same time, resources are occupied by a large number of retry requests, causing the server load to be too high in the prior art.

[0005] The present application discloses a request processing method, an application program is installed in an electronic device, the electronic device is in communication connection with a network attached storage device, and the network attached storage device is accessed through the application program, and the request processing method comprises the following steps:

[0006] Obtaining request information, generating and initiating an original request according to the request information, and recording an original timestamp of the original request;

[0007] Obtaining a response state of the original request, if the response state is a response failure, determining whether the request information meets a preset retry requirement;

[0008] If yes, obtaining a remaining duration based on a current time and the original timestamp, and determining whether the remaining duration exceeds a preset duration threshold;

[0009] If yes, applying for obtaining a reentrant lock, when the reentrant lock is obtained, modifying an original mark header of the original request into a retry mark header to generate a retry request;

[0010] Initiating the retry request, asynchronously processing the retry request, obtaining a request result and counting the request result into a log, and releasing the reentrant lock.

[0011] Optionally, after the step of applying for the reentrant lock, the method comprises:

[0012] When the reentrant lock is in a held state, a retry task corresponding to the original request is added to a waiting queue;

[0013] When the reentrant lock is released, a target retry task is selected from the waiting queue in an order in which the retry tasks are added to the waiting queue, and the reentrant lock is assigned to the target retry task.

[0014] Optionally, after the step of adding the retry task corresponding to the original request to the waiting queue, the method comprises:

[0015] The remaining time length is taken as a waiting threshold of the retry task, and when a time length of the retry task in the waiting queue exceeds the waiting threshold, the retry task is automatically exited from the waiting queue.

[0016] Optionally, the step of applying for the reentrant lock comprises:

[0017] The reentrant lock is applied for in a wrapped code block, the wrapped code block is used for wrapping a risky operation that has a risk of causing an exception, when the reentrant lock is acquired, a retry parameter is set and the retry request is initiated according to the retry parameter;

[0018] If an exception occurs in the operation in the wrapped code block, the operation jumps to a capture block, the capture block is used for capturing the exception thrown by the wrapped code block, the exception is captured in the capture block, and the exception is recorded in a log;

[0019] Regardless of whether the exception occurs or not, the operation of releasing the reentrant lock is executed in an execution block, the execution block contains logic that is executed regardless of whether the exception occurs or not.

[0020] Optionally, the request information comprises a request address and a request content, and the step of judging whether the request information meets a preset retry requirement comprises:

[0021] The request content comprises a connection mode of the client and the server, and it is judged whether the connection mode is a preset connection mode; if yes, it is determined that the request information meets the preset retry requirement;

[0022] and / or

[0023] A key field of the request address is read, it is judged whether the original request is a target type request, and if no, it is determined that the request information meets the preset retry requirement.

[0024] Optionally, the preset connection mode comprises a point-to-point connection and a self-built server forwarding.

[0025] and / or

[0026] The target type request is a heartbeat request.

[0027] Optionally, before the step of initiating the retry request, the method comprises:

[0028] A network detection method is called to detect and repair the network connection.

[0029] The application further discloses an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the computer program is executed by the processor to enable the processor to perform the steps as described above.

[0030] The application further discloses a request processing system of an application program, a network attached storage device and the electronic device as described above, wherein the electronic device is installed with the application program capable of performing the steps of the method as described above.

[0031] The application further discloses a computer readable storage medium storing a computer program, wherein the computer program is executed by a processor to enable the processor to perform the steps as described above.

[0032] Compared with the prior art, the request processing method provided by the embodiment of the application has the following beneficial effects:

[0033] The original timestamp of the original request is recorded, the current time is obtained when the original request fails, the remaining duration is obtained based on the current time and the original timestamp, and it is determined whether the remaining duration exceeds a preset duration threshold, so that it is ensured that the retry does not prolong the request time unlimitedly, and the request is prevented from waiting unlimitedly. It is determined whether the request information meets the preset retry requirement, and only when the original request fails to meet the preset retry requirement, the retry is performed, so that the original request without significance or with a low success probability of retry is automatically filtered, system resources and network bandwidth are prevented from being wasted, and the utilization efficiency of system resources is improved. The number of concurrent retry requests is controlled through the reentrant lock, a large number of failed requests are prevented from being simultaneously retried, and the problems of exhaustion of system resources and server crash are prevented. BRIEF DESCRIPTION OF DRAWINGS

[0034] The scheme of the application will be further described in detail below with reference to the drawings and embodiments, and the drawings show:

[0035] Figure 1 is a flowchart of an embodiment of the request processing method provided by the application;

[0036] Figure 2 is a schematic diagram of an application scenario of the request processing method provided by the application;

[0037] Figure 3 is a schematic diagram of the internal structure of an electronic device in an embodiment provided by the application.

[0038] The same reference signs refer to the same components throughout the drawings.

[0039] 1, electronic device; 2, network attached storage device. DETAILED DESCRIPTION

[0040] It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict. Now, the preferred embodiments of the present application will be described in detail with reference to the drawings.

[0041] Please refer to Figure 1 and Figure 2 , Figure 1 is a flowchart of an embodiment of the request processing method provided by the present application, Figure 2 is a schematic diagram of the application scenario of the request processing method provided by the present application. As shown in Figure 2 , the electronic device 1 establishes a communication connection with the network attached storage device 2. The electronic device 1 is installed with an application program, and accesses the network attached storage device 2 through the application program. The electronic device 1 network attached storage device 2 The electronic device 1 can initiate various requests to the network attached storage device 2, and the network attached storage device 2 can perform corresponding operations in response to these requests, but network connection interruption or server downtime and other problems will cause the request to fail, at this time, the electronic device 1 can perform a retry operation, the specific content is as shown in Figure 1 .

[0042] The request processing method provided by the present application comprises the following steps:

[0043] S101: Obtain request information, generate and initiate an original request according to the request information, and record the original timestamp of the original request.

[0044] In a specific implementation scenario, the original request object is saved, and the request information of the original request is obtained through the attributes or methods of the request object, such as the URL, method, and header information of the original request. In the present embodiment, the request information includes the request content and the request address (URL).

[0045] The original timestamp startTime of the original request is recorded, which can be obtained by using the system-provided time function or tool class. The original request is initiated by calling next.handle(context). next.handle(context) will actually trigger the sending of the request, that is, initiate a network request to the server. In this way, it can be ensured that the request can be sent to the server and processed. In some cases, the network request can be asynchronous, and by calling next.handle(context), it can be ensured that the request is sent in the correct order and the response of the request can be processed correctly.

[0046] The URL of the original request can record specific information of the request, facilitating subsequent log recording and tracking. Further, a unique ID (taskId) of the request task can be generated for the original request, creating a corresponding unique identifier for each original request, which can be used for subsequent lock management, retry control, or other scenarios requiring differentiation of different requests, helping to ensure tracking and management of requests, so as to better handle the retry logic of the request and record related information.

[0047] S102: Obtain the response status of the original request. If the response status is response failure, determine whether the request information meets the preset retry requirement. If yes, execute step S103.

[0048] In a specific implementation scenario, the success or failure of the original request is determined according to the status code of the response. The HTTP protocol defines a series of status codes, among which the status codes in the range of 200-299 represent request success. Common success status codes include 200 (OK), 201 (Created), 202 (Accepted), etc. If it is determined that the response code is in the range of 200-299, it can be confirmed that the response status is response success, the original request has been successfully processed and the correct response has been obtained, and no retry is needed.

[0049] If the response code is not in the preset range, it can be determined that the response status is response failure. First, the corresponding failure log is recorded according to the unique ID established in the previous step, which can better track problems, analyze failure causes and perform subsequent problem positioning, helping system maintenance and troubleshooting. The failure log can include the following contents: request information, such as the URL, method, parameters, etc. of the request. The specific reason for the request failure, such as network problem, server problem, permission problem, etc. The time of failure occurrence, facilitating subsequent search and comparison. System environment information when the request fails, such as operating system, application program version, etc., which helps to locate the problem.

[0050] Retry operation consumes system resources, including network bandwidth, server computing resources, etc. Too many retries can have a negative impact on system performance, and some requests are not suitable for retry, such as one-time requests or irreversible requests, which may lead to unexpected results. Therefore, it is necessary to determine whether the request information meets the preset retry requirement, for example, based on the connection method, request type, request content, etc. parameters in the request information to determine whether the original request can be retried after the request fails.

[0051] By carefully designing the judgment conditions, it is possible to avoid retrying all requests, but only those that are truly likely to succeed and are meaningful to the business. This fine-grained control can effectively reduce the system burden, reduce unnecessary retries, and improve the overall performance and stability of the system.

[0052] Specifically, the UgService.loginService?.requestCanRetry() method can be called to determine whether the current request information supports retry based on the return result of the method. If the return result is true, it means that retry is supported. Otherwise, if the return result is false, it means that retry is not suitable, and these scenarios that are not suitable for retry can be filtered out to avoid unnecessary retry operations. UgService is a service class responsible for handling user login-related functions, and loginService is a property or method in the UgService class that is specifically used to handle user login-related logic. requestCanRetry() is a method used to determine whether the current request can be retried, which can be based on some conditions or rules to determine whether the original request should be retried, such as checking the current network state, login method, request content, etc.

[0053] In one implementation scenario, the key fields of the request address are checked, and based on the key fields, it is determined whether the original request is a target type request. If so, no retry operation is performed based on the original request. The target type request is a request that does not involve specific business logic, and retrying such a request will not change any state or result. Therefore, in order to reduce the burden on the system, no retry operation is performed on the target type request. Some types of requests have high retry costs, which may increase the system burden, consume resources, or cause other adverse effects. Retrying may have a negative impact on the overall performance and stability of the system.

[0054] For example, the target type request can be a heartbeat request. If the request address (URL) includes / ugreen / v1 / verify / heartbeat, it can be confirmed that the original request is a heartbeat request, which is used to detect whether the system is alive or running normally. Such a request usually does not contain actual business data, but is used to maintain the connection or monitor the health status of the system. Heartbeat check requests are usually sent periodically and have a high frequency. Retrying such requests may cause excessive system burden and affect system performance. Heartbeat request failure is due to internal or external problems in the system, and retrying cannot solve these fundamental problems, so retrying cannot make the request successful. Unnecessary retries on such requests may generate unnecessary system overhead.

[0055] In another implementation scenario, the connection mode of the electronic device and the server is obtained based on the request content, and if the connection mode belongs to a preset connection mode, it is determined that the request information meets the preset retry requirement. Different connection modes can have different characteristics and stability, and the cost or overhead of retry can be known based on the characteristics and stability. Therefore, for some types of connection modes, retry can be performed to increase the success rate, while for some types of connection modes, retry is not necessary to avoid unnecessary overhead.

[0056] For example, the preset connection mode can be a point-to-point connection (P2P) mode or a self-built server forwarding mode. The self-built server cluster is completely autonomous and controllable, can be predictably expanded, and can withstand sudden retry traffic. The server has automatic load balancing capability. In P2P connection, the direct connection between terminal devices does not depend on third-party infrastructure, supports ICE protocol automatic candidate path switching, and retry after NAT penetration failure can trigger a more optimal routing path. When there is temporary network jitter, retry can avoid unnecessary service interruption.

[0057] Other types of connection modes, such as public IPv4, local IPv4, IPv6, and DDNS, do not belong to the preset connection mode.

[0058] S103: Obtain the remaining duration based on the current time and the original timestamp, and determine whether the remaining duration exceeds a preset duration threshold. If so, perform step S104.

[0059] In a specific implementation scenario, time management is required during retry to avoid request total time expansion caused by blind retry. The connection timeout duration is obtained from the request information of the original request, and the default is 15 seconds. This duration is the maximum time allowed by the system for the client and the server to establish a connection and complete a request.

[0060] Based on the original timestamp (startTime) obtained in step S101 and the current time (endTime), the difference between the current time and the original timestamp can be used to obtain the consumed time. The connection timeout duration minus the consumed time can obtain the remaining duration. Determine whether the remaining duration exceeds a preset duration threshold. The preset duration threshold can be flexibly adjusted according to actual needs, for example, it can be set to 1 second in this implementation scenario.

[0061] Only when the remaining duration is long enough (exceeds the preset duration threshold) to perform the retry, avoiding invalid retries in the case of insufficient time, thereby optimizing the efficiency of network requests and user experience. Because when the remaining duration is too short, the retry is almost bound to fail, because the short time is not enough to complete a complete retry request, and also prolongs the total request time. For example, when there are 0.5 seconds left, 0.5 seconds is not enough to complete TCP handshake + request + response, for example, the retry request takes 1 second, resulting in a final request time of 15.5 seconds, exceeding the set connection timeout duration (15 seconds). In this way, the retry not only fails to succeed, but also prolongs the total request time, and the user needs to wait longer, but the result is still a failure, and the user experience is poor.

[0062] S104: Apply for a reentrant lock, and when the reentrant lock is acquired, modify the original mark header of the original request to a retry mark header to generate a retry request.

[0063] In a specific implementation scenario, the remaining duration exceeds the preset duration threshold, so the retry request can be executed. In order to avoid the situation of resource competition, resource exhaustion, etc. caused by simultaneous retries after a large number of request failures, the number of retries is controlled through the reentrant lock in this embodiment. The reentrant lock is a special lock mechanism that allows the same thread to acquire the lock multiple times while holding the lock, without causing deadlock. However, only the holding thread of the lock can reenter, and other threads will still be blocked. Therefore, if multiple threads simultaneously attempt to acquire the same lock resource, only one thread can successfully acquire the lock, and other threads will be blocked until the thread that acquired the lock releases the lock. In this case, only one retry request can enter the locked state at the same time, and other retry requests will be blocked and wait for the release of the lock resource.

[0064] First, acquire the holding state of the reentrant lock. Based on the holding state of the reentrant lock, the current retry activity can also be acquired. If the current retry activity is high, the reentrant lock will be in a held state for a long time. For example, it can be detected by the ReentrantLock.getInstance().isLocked() method. By detecting the detection result, it can be known whether other retry operations are currently being performed, in order to avoid conflicts between retry operations. When the reentrant lock is in an idle state, the reentrant lock can be acquired without complex competition procedures. If the reentrant lock is in a held state, the retry task is added to the waiting queue. This significantly reduces the performance overhead in low-concurrency scenarios.

[0065] In one implementation scenario, the reentrant lock is in an idle state, and the reentrant lock can be acquired, for example, by trying to acquire the reentrant lock through the tryLock(remainingTime, taskId) method. After the reentrant lock has been acquired, the retry times field hm-attempts-times is inserted in the request header object, and the original request is modified from the original mark header to a retry mark header to generate a retry request. The key-value pairs of the original request header remain unchanged except for the newly added field.

[0066] In another implementation scenario, the reentrant lock is in a held state, and the remaining time is used as a waiting threshold for the retry task. If the time of the retry task in the waiting queue exceeds the waiting threshold, the retry task is automatically removed from the waiting queue. In this way, the lock can be tried to be acquired within the remaining time, and request delay caused by long waiting time can be avoided. In this way, it is ensured that the lock competition process does not cause the total request time to exceed the preset connection timeout time. As the remaining time decreases in real time, the lock waiting strategy can be adaptively adjusted, and non-critical operations can be actively abandoned when time is urgent.

[0067] In one implementation scenario, when the lock acquisition fails, a complete failure log context record (including competition time, task identification, and other diagnostic information) is recorded instead of simply throwing an error. In this way, forced retry in the case of failed lock acquisition can be avoided, and system resource waste and performance degradation can be avoided. This processing method meets the needs of fault diagnosis and ensures that the business logic is not affected by lock competition.

[0068] The lock mechanism internally implements queue management, timeout cleaning, and deadlock detection functions. A reliable system is constructed through a trinity maintenance mechanism. Queue management implements fair scheduling of requests. When the reentrant lock is released, the next retry task is selected and activated from the waiting queue according to a strict queue scheduling algorithm, for example, the target retry task is selected according to the order of joining the waiting queue, and the reentrant lock is assigned to the target retry task. Timeout cleaning can periodically release deadlocks to avoid resource leakage. Deadlock detection can avoid the system from being in a deadlock state. These mechanisms together form a self-healing system for the lock service, which can still remain stable under continuous high load.

[0069] S105: Initiating a retry request, asynchronously processing the retry request, obtaining a request result and logging the request result, and releasing the reentrant lock.

[0070] In a specific implementation scenario, the retry request is initiated by calling the standardized interface next.handle(context). When initiating the retry request, ensure that the retry request is exactly the same as the original request except for the added retry marker field, for example, the request body binary content is completely reused, the target URL and query parameters are unchanged, and the connection timeout and other configuration parameters inherit the request information of the original request. In this way, it can be ensured that the retry request is consistent with the original request in terms of request body and other aspects.

[0071] When performing network communication, it is often necessary to wait for the server response. If the program execution is blocked while waiting for the response, it will cause the program to become very inefficient. Therefore, designing the request as an asynchronous operation can allow the program to continue executing other tasks while waiting for the response, improving the concurrency and efficiency of the program. Using Promise to manage the callback domain problem when handling asynchronous tasks such as asynchronous operation processing requests. When processing asynchronous operations, traditional callback functions can cause callback domain, i.e. multiple nested callback functions, making the code difficult to understand and maintain. Promise provides a more elegant way to handle asynchronous operations, which can more clearly express the execution and result processing logic of asynchronous operations.

[0072] In the then branch of the Promise, the success case of the request is handled, i.e. the success case of the retry request, for example, triggered when receiving an HTTP 2xx response, verify the status code and record the structured success log; in the catch branch, the failure case of the request is handled, i.e. the failure case of the retry request, for example, intercept network errors or server 5xx responses, generate error feature summary. In this way, it can be ensured that the processing of the retry request result is asynchronous and orderly.

[0073] According to the result of the retry request, the corresponding success or failure log is recorded. In the log, the code of the unique ID is added to track the execution of the retry request. The success log includes the retry marker field value, the server response timestamp, and the final status code. The failure log includes the error type classification (network timeout, protocol error, etc.), the time when the retry occurred, and the unique ID corresponding to the original request. The log can use a non-blocking writing mode to avoid affecting the performance of the main request processing.

[0074] In one implementation scenario, when performing the retry process, the entire process is surrounded by a try-catch-finally structure, which can effectively capture possible exceptions and perform corresponding processing logic when exceptions occur, while ensuring correct release of resources. The try block (wraps the code block) as a risk operation container, which is used to wrap risky operations that may cause exceptions, encapsulates all critical section codes that may throw exceptions, such as acquiring a reentrant lock, if the lock is successfully acquired, a series of logic is executed, such as setting retry parameters (e.g., number of retries), and performing retry operations according to the retry parameters. When any statement throws an exception (such as lock acquisition timeout, network IO error, etc.), the code flow will immediately interrupt the execution of the current try block and jump to the corresponding catch block (capture block). When no exception occurs, it directly enters the finally block (execution block) after executing all statements.

[0075] The catch block captures the exceptions thrown in the try block, takes a silent degradation strategy after capturing the exception, records the error context (such as request URL, exception type) to the log system, and returns the original failure response (res) instead of propagating the exception, thereby converting failures in the retry process into observable log events instead of runtime errors affecting the main process.

[0076] In the finally (execution block) block, there is logic that will be executed regardless of whether an exception occurs or not. In this embodiment, the logic is to release the reentrant lock regardless of whether the try block is successfully executed or the catch block handles the exception, to ensure that the lock is not leaked due to exceptions (to avoid deadlocks), and to allow other retry tasks in the waiting queue to acquire the lock in a timely manner. By accurately matching the lock holder with taskId, it is ensured that only the current thread can release the lock it holds, preventing the incorrect release of other threads' locks (cross-thread safety).

[0077] The try-catch-finally structure helps improve the robustness of the code, ensures that resources are released correctly, and can handle potential exceptions, making the program more stable and reliable.

[0078] In other implementation scenarios, before initiating the retry request, a network detection method is called to detect and repair the network connection. For example, before retrying, the UgService.loginService?.autoTestConnect() method is called to actively detect and attempt to repair the network connection, which can immediately attempt to repair network connection problems when a request fails, thereby improving the stability and reliability of network connections. This approach helps improve the robustness of the system and reduces the number of request failures caused by network problems.

[0079] `autoTestConnect()` proactively detects the current network stack status, such as checking TCP / IP layer connectivity (e.g., whether DNS can be resolved, TCP handshake completed), verifying proxy / VPN tunnel stability, and triggering network module resets when necessary (e.g., releasing old connection pools, switching APNs). Unlike passively waiting for retries, it proactively intervenes in the network status immediately upon failure, rather than relying on the randomness of the retries themselves to improve the connection. Network detection precedes the actual retry request. If a transient interruption is detected (e.g., delay when switching from WiFi to cellular), it may quickly restore the connection by resetting the network configuration, preventing subsequent retries from failing. If a persistent fault is identified (e.g., airplane mode is not turned off), invalid retries can be terminated in advance, saving device resources.

[0080] By using network layer health checks as a prerequisite for retries, the effectiveness of retries is improved through proactive fault diagnosis. Its advantage lies not in increasing the number of retries, but in ensuring that each retrieval occurs when the network is available through intelligent screening, thereby achieving a higher final success rate within the same time budget.

[0081] As described above, this embodiment records the original timestamp of the original request. When the original request fails, the current time is obtained, and the remaining duration is calculated based on the current time and the original timestamp. It then determines whether the remaining duration exceeds a preset duration threshold to ensure that retries do not indefinitely prolong the request time and avoid infinite waiting. The system also checks whether the request information meets preset retry requirements. Only original requests that meet these requirements can be retried after failure, automatically filtering out meaningless or low-probability retry requests, thus avoiding wasting system resources and network bandwidth and improving system resource utilization efficiency. Finally, a reentrant lock controls the number of concurrent retry requests, preventing a large number of failed requests from retrying simultaneously and thus preventing system resource exhaustion.

[0082] Figure 3 A schematic diagram of the internal structure of an electronic device in one embodiment is shown. This electronic device can specifically be a terminal or a server. Figure 3 As shown, the electronic device includes a processor, a memory, and a network interface connected via a system bus. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and may also store a computer program. When executed by the processor, this computer program enables the processor to implement application request processing methods. The internal memory may also store a computer program, which, when executed by the processor, enables the processor to implement application request processing methods. Those skilled in the art will understand that... Figure 3The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the electronic device to which the scheme of the present application is applied. The specific electronic device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0083] In one embodiment, an electronic device is provided, comprising a memory and a processor, the memory storing a computer program, the computer program being executed by the processor to cause the processor to perform the steps as above.

[0084] In one embodiment, a computer readable storage medium is provided, storing a computer program, the computer program being executed by a processor to cause the processor to perform the steps as above.

[0085] The present application also provides a system for processing a request of an application program, the system for processing a version of an application program comprising the electronic device and the network-attached storage device as described above, and the electronic device is installed with an application program capable of executing the steps of the method as described above.

[0086] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware, and the program can be stored in a non-volatile computer readable storage medium. When the program is executed, it can include the processes of the above-mentioned embodiments. Any reference to memory, storage, database or other medium used in the embodiments provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0087] The technical features of the above embodiments can be combined in any way. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described, but as long as the combinations of the technical features do not exist, they should be considered as the scope of the present application.

[0088] It should be understood that the above examples are only used to illustrate the technical solutions of the present application, but not limit the technical solutions of the present application. Those skilled in the art can make modifications to the technical solutions described in the above examples, or make equivalent replacements to some of the technical features. All these modifications and replacements shall fall within the protection scope of the present application.

Claims

1. A request processing method of an application program, characterized by, The application is installed in an electronic device, the electronic device is connected with a network attached storage device, and the network attached storage device is accessed through the application, and the request processing method comprises: Obtaining request information, generating and initiating an original request according to the request information, and recording an original timestamp of the original request; Obtaining a response state of the original request, if the response state is a response failure, judging whether the request information meets a preset retry requirement; If yes, obtaining a remaining time based on a current time and the original timestamp, and judging whether the remaining time exceeds a preset time threshold; If yes, applying for obtaining a reentrant lock, and when the reentrant lock is obtained, modifying an original mark header of the original request into a retry mark header to generate a retry request; Initiating the retry request, asynchronously processing the retry request, obtaining a request result and recording the request result in a log, and releasing the reentrant lock.

2. The request processing method of an application program according to claim 1, characterized by, After the step of applying for obtaining the reentrant lock, comprising: When the reentrant lock is in a held state, adding a retry task corresponding to the original request to a waiting queue; When the reentrant lock is released, selecting a target retry task from the waiting queue in an order of adding the waiting queue, and allocating the reentrant lock to the target retry task.

3. The request processing method of an application program according to claim 2, wherein After the step of adding the retry task corresponding to the original request to the waiting queue, comprising: Taking the remaining time as a waiting threshold of the retry task, and when a time of the retry task in the waiting queue exceeds the waiting threshold, automatically exiting the waiting queue.

4. The request processing method of an application program according to Claim 2, characterized by, The step of applying for obtaining the reentrant lock, comprising: Applying for obtaining the reentrant lock in a wrapped code block, the wrapped code block being used for wrapping a risk operation with a risk of causing an exception, setting a retry parameter and initiating the retry request according to the retry parameter when the reentrant lock is obtained; If an exception occurs in the operation in the wrapped code block, jumping to a capture block, the capture block being used for capturing the exception thrown by the wrapped code block, capturing the exception in the capture block, and recording the exception in a log; In an execution block, whether the exception occurs or not, an operation of releasing the reentrant lock is executed, and the execution block contains logic that is executed regardless of whether the exception occurs or not.

5. The request processing method of an application program according to Claim 1, wherein The request information comprises a request address and a request content, and the step of judging whether the request information meets a preset retry requirement comprises: The request content comprises a connection mode of the client and the server, and whether the connection mode is a preset connection mode is judged; if yes, it is determined that the request information meets the preset retry requirement; And / or A key field of the request address is read, whether the original request is a target type request is judged, and if not, it is determined that the request information meets the preset retry requirement.

6. The request processing method of an application program according to Claim 5, characterized by, The preset connection mode comprises a point-to-point connection and a self-built server forwarding; And / or The target type request is a heartbeat request.

7. The request processing method of an application program according to Claim 1, wherein Before the step of initiating the retry request, comprising: Calling a network detection method to detect and repair the network connection.

8. An electronic device, comprising: A computer program product comprising a memory storing a computer program, and an executor, which, when the computer program is executed by the executor, causes the executor to perform the steps of the method according to any one of claims 1 to 7.

9. A request processing system of an application program, characterized by, The system comprises a network attached storage device and an electronic device according to claim 8, in which an application program is installed, which is capable of performing the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program product comprising a memory storing a computer program, and an executor, which, when the computer program is executed by the executor, causes the executor to perform the steps of the method according to any one of claims 1 to 7.

Images