Time-out processing method, electronic device, storage medium and computer program product

Abstract

The application provides an overtime processing method, an electronic device, a storage medium and a computer program product, comprising: creating an asynchronous thread by a target thread; executing an asynchronous calling method by the asynchronous thread, in the asynchronous calling method, sending a remote calling request to a target server and waiting for receiving a request result returned by the target server, the asynchronous calling method being provided with a first overtime, the first overtime being used for limiting a maximum waiting time length after the remote calling request is sent to the target server; from the beginning of creating the asynchronous thread by the target thread, waiting for obtaining an execution result of the asynchronous calling method by the target thread, and determining that the remote calling is overtime when the execution result is not obtained within a second overtime, wherein the execution result is generated based on a return condition of the request result within the first overtime, and the second overtime is equal to the first overtime. The overtime processing method provided by the application can ensure that the actual waiting time in the remote calling process does not exceed the second overtime.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a timeout handling method, an electronic device, a storage medium, and a computer program product. Background Technology

[0002] Remote procedure calls (RPCs) are a fundamental communication technology in distributed systems. A complete remote procedure call, from initiation to termination, constitutes the entire remote procedure call chain. gRPC, as one of the remote procedure call frameworks, has seen rapid development in the cloud-native and distributed system fields in recent years, especially with the rapid development of the Kubernetes cloud platform, which has brought increasing attention to gRPC. In a remote procedure call implemented based on gRPC, the client first establishes a connection with the server, then the client sends a remote procedure call request to the server. After receiving and processing the request, the server returns the result to the client. However, in actual production environments, there is a problem with the preset timeout period becoming invalid. For example, when a node in the Kubernetes cluster where the gRPC server resides fails, the actual time taken for the business gRPC client to call the server far exceeds the timeout period set in the program. Summary of the Invention

[0003] This invention addresses the aforementioned problems. Embodiments of this invention disclose a timeout handling method, an electronic device, a storage medium, and a computer program product. In the timeout handling method provided by this technical solution, an asynchronous thread is created by the target thread, and an asynchronous method is executed within the asynchronous thread. Starting from the creation of the asynchronous thread, the target thread waits for the execution result of the asynchronous method within a second timeout period. If no execution result is obtained after the second timeout period, it indicates that the client has not received the requested result returned by the target server, thus determining a remote call timeout. The starting point of the second timeout period is the moment the target thread creates the asynchronous thread. Therefore, the second timeout period can at least cover the connection establishment phase of the asynchronous method executed by the asynchronous thread. This avoids the problem that the first timeout set in the asynchronous method is ineffective during the connection establishment phase, thereby ensuring that the actual waiting time during the remote call does not exceed the second timeout period. Furthermore, since the second timeout period is equal to the first timeout period, it ensures that the actual time consumed by the remote call process will not exceed the timeout period set by the program. For example, it can ensure that the actual time consumed by a business gRPC client calling a server will not exceed the timeout period set by the program. Determining the remote call timeout using a second timeout period avoids the problem of preset timeouts becoming invalid, ensures more accurate timeout determination, facilitates subsequent timeout exception handling logic, improves overall stability, and helps avoid the risk of cascading failures due to a backlog of business requests. Furthermore, the timeout handling method does not alter the source code of the asynchronous call method, making it easier to implement.

[0004] According to one aspect of the present invention, a timeout handling method is provided, comprising: in response to a business request, a target thread creating an asynchronous thread; the asynchronous thread executing an asynchronous call method, wherein the asynchronous call method sends a remote call request to a target server and waits to receive a request result returned by the target server, the asynchronous call method being configured with a first timeout period, the first timeout period being used to limit the maximum waiting time after sending the remote call request to the target server; starting from the creation of the asynchronous thread by the target thread, the target thread waiting to obtain the execution result of the asynchronous call method, and if no execution result is obtained after a second timeout period, the remote call is determined to have timed out, wherein the execution result is generated based on the return status of the request result within the first timeout period, and the second timeout period is equal to the first timeout period; and the target thread executing a first failure callback method when the remote call times out.

[0005] For example, in the asynchronous call method, the asynchronous result container waits to receive the request result returned by the target server. The asynchronous result container is equipped with a first callback interface, which is used to listen to the asynchronous result container and generate the execution result based on the return status of the request result in the asynchronous result container.

[0006] For example, the target thread waits to obtain the execution result of the asynchronously called method. If the execution result is not obtained after the second timeout period, the remote call is determined to have timed out. This includes: the target thread listens for the execution result through the second callback interface, and determines that the remote call has timed out when the execution result is not obtained after the second timeout period through the second callback interface, and determines that the remote call has not timed out when the execution result is obtained within the second timeout period.

[0007] For example, generating an execution result based on the return status of the request result within the asynchronous result container includes: if the asynchronous result container has a request result returned within a first timeout period, then executing a first success callback method to obtain the execution result; in the first success callback method, if the request result is normal, then generating an execution result indicating that the remote call is normal, and if the request result is abnormal, then generating an execution result indicating that the remote call is abnormal; the timeout handling method further includes: if the asynchronous result container does not have a request result returned within the first timeout period, then executing a second failure callback method; in the second failure callback method, switching the target server from the current server to the next server.

[0008] For example, the process of the target thread waiting to obtain the execution result of the asynchronous method call, and determining that the remote call has timed out if the execution result is not obtained after a second timeout period, includes: the target thread listening for the execution result through a second callback interface, and determining that the remote call has timed out if the execution result is not obtained after the second timeout period through the second callback interface; and determining that the remote call has not timed out if the execution result is obtained within the second timeout period. The timeout handling method further includes: if the execution result indicates that the remote call is normal when the remote call has not timed out, the target thread executing the second success callback method through the second callback interface; if the execution result indicates that the remote call is abnormal, the first failure callback method is executed. The execution of the first failure callback method by the target thread when the remote call times out includes: the target thread executing the first failure callback method when the remote call times out through the second callback interface. The second success callback method is used to determine that the asynchronous method call has been successfully executed and exit the asynchronous thread, and the first failure callback method is used to switch the target server from the current server to the next server.

[0009] For example, in the second failure callback method or the first failure callback method, the next server is specified by the distributed server, or the next server is automatically selected.

[0010] For example, the target thread has a countdown counter set to 1 initially, and the first failure callback method is also used to reset the countdown counter to 0 to release the asynchronous thread.

[0011] According to another aspect of the present invention, an electronic device is provided. The electronic device includes a processor and a memory, the memory storing computer program instructions, which, when executed by the processor, are used to perform any of the timeout handling methods described above.

[0012] According to another aspect of the present invention, a storage medium is provided on which program instructions are stored, which, when executed, are used to perform any of the timeout handling methods described above.

[0013] According to another aspect of the present invention, a computer program product is provided, comprising computer program instructions that, when executed, perform any of the timeout handling methods described above.

[0014] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0015] The following figures are included as part of this invention for understanding its principles. The figures illustrate embodiments of the invention and their descriptions, serving to explain the principles of the invention. In the figures,

[0016] Figure 1 A flowchart illustrating a timeout handling method according to an exemplary embodiment of the present invention is shown;

[0017] Figure 2 A flowchart illustrating a timeout handling method corresponding to an asynchronous call method executed by an asynchronous thread according to an exemplary embodiment of the present invention is shown.

[0018] Figure 3 A schematic block diagram of a timeout processing apparatus according to an exemplary embodiment of the present invention is shown; and

[0019] Figure 4 A schematic block diagram of an electronic device according to an exemplary embodiment of the present invention is shown. Detailed Implementation

[0020] The user data, data acquisition, and / or use involved in the embodiments of this application strictly comply with the laws, regulations, and industry standards of relevant countries and regions. The collection and acquisition of data involved in the embodiments of this application are all done in advance by actively prompting or prominently displaying information to inform users and obtaining authorization, or by obtaining full authorization from all parties. The processing, manipulation, forwarding, and use of data involved in the embodiments of this application are all carried out on the premise that the user or relevant party is fully informed and authorized. In implementing the various embodiments of this application, the types of data or information, applicable scope, and usage scenarios that may be involved are informed to users or relevant parties and authorization is obtained through appropriate means. The specific methods of notification and authorization may vary according to actual circumstances, and this application is not limited in this regard. The processing of personal information involved in the embodiments of this application is carried out under the premise of having a legal basis (such as obtaining the consent of the personal information subject or being necessary for the performance of a contract), and is only processed within the scope stipulated or agreed. Sensitive personal information such as biometric information, medical and health information, financial account information, and precise location information involved in the embodiments of this application are all processed under the premise of having a specific purpose and sufficient necessity, and with the separate authorization and consent of the user or relevant party. In some embodiments of this application, if the user or related party refuses to process personal information other than the information necessary for the basic functions, it will not affect the use of the basic functions of the embodiments of this application.

[0021] To make the objectives, technical solutions, and advantages of the present invention more apparent, exemplary embodiments according to the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. It should be understood that the present invention is not limited to the exemplary embodiments described herein. Based on the embodiments of the present invention described herein, all other embodiments obtained by those skilled in the art without inventive effort should fall within the protection scope of the present invention.

[0022] As mentioned above, in remote calls implemented using gRPC, a timeout period is typically set. This timeout is usually configured using gRPC's native timeout mechanism; for example, it can be set to 1 second via the gRPC client. The start point of this timeout is defined as the moment the client successfully sends the remote call request and begins waiting to receive the server's response. If the client does not receive the server's response within this timeout period, the remote call has timed out. However, in gRPC-based remote calls, the client needs to establish a connection with the server before sending the remote call request. Since the connection establishment phase occurs before the timeout start point, there is a blind spot in timeout monitoring during this phase. The set timeout is only used for timeout detection after the client sends the remote call request; it is not effective during the connection establishment phase. When problems occur during the connection establishment phase, such as the inability to establish a connection or connection interruption, specifically, the server's Kubernetes cluster node may fail, causing connection establishment to fail. In this case, the client will wait or continuously attempt to establish a connection with the server until it is finally confirmed that the connection is unreachable. This process can last for tens of seconds. During this process, Kubernetes' failover feature cannot be used to redistribute requests to other healthy nodes. Because the timeout settings customized by the gRPC client are not effective, the business side cannot trigger business retries through the timeout exception handling customized by the gRPC client. The remote call chain can only return to normal after Kubernetes removes the failed node from the cluster. The entire process of the client waiting or continuously attempting to connect to the server may only last a short period of tens of seconds, but the number of client requests affected during this time is relatively large. Such blocking will have a significant impact on the overall system.

[0023] To at least partially address the problem of timeout failures in existing gRPC calls, thus preventing the execution of timeout exception handling, a timeout handling method is provided according to one aspect of the present invention. This method can be applied to any electronic device with instruction execution capabilities, i.e., executed by the electronic device. The electronic device may include, but is not limited to, personal computers, servers, mobile terminals, etc. The server may be an independent physical server, a server cluster, or a cloud server capable of cloud computing. For example, the electronic device may be a business server. Any type of application with remote call functionality can be deployed on the electronic device, through which the timeout handling method for remote calls can be implemented. The application with remote call functionality can connect to the server cluster that actually provides the service to form a remote call link. This does not limit the application to directly executing the timeout handling method, but rather refers to the application being able to execute instructions related to the remote call timeout handling method, and the timeout handling method provided by the present invention enabling timeout monitoring of the remote call link. Specifically, the timeout handling method can be implemented by the processor calling computer-readable program instructions stored in the memory of the electronic device. The business described in this article can be any type of business related to remote procedure calls and can belong to any domain. Accordingly, the timeout handling method can be applied to various domains such as microservice remote calls or cross-node communication based on gRPC.

[0024] Figure 1 A flowchart illustrating a timeout handling method according to an exemplary embodiment of the present invention is shown. Figure 1 As shown, the timeout handling method includes the following steps S11, S12, S13 and S14.

[0025] Step S11: In response to the business request, an asynchronous thread is created by the target thread.

[0026] The maintenance of electronic devices involves a target thread. From the moment the target thread receives a business request until the request is completed, this can be considered a complete remote call chain. For example, an application with remote call functionality can receive a user's business request; once the application receives the request, the target thread also receives it.

[0027] The target thread is the thread used to receive business requests and schedule other threads to process them. It can be any type of thread, such as the main thread, worker threads, asynchronous callback threads, scheduled task threads, dedicated communication threads (like the Netty thread in gRPC), etc. The main thread is the core execution thread handling the current business request, responsible for flow control, task distribution, and result aggregation. The main thread can break down the task corresponding to the business request into multiple subtasks, which are then processed in parallel by worker threads in the thread pool. Each worker thread can independently initiate remote calls. An asynchronous callback thread is a thread scheduled by the framework or thread pool to execute predefined callback logic when an asynchronous operation (such as a remote call, I / O operation, or scheduled task) completes. A scheduled task thread is a thread created and maintained by a scheduling framework (such as Quartz, Spring Scheduled, Java Timer, etc.) that executes specific tasks according to a predetermined time period or delay rules. A communication thread (or network communication thread, I / O thread) is a thread specifically responsible for handling network communication events, including listening for connections, receiving requests, sending responses, and managing network connection states, without executing business logic. This article primarily uses the target thread as the main thread for description, but this is not a limitation of the invention. The target thread can receive business requests and respond to them by creating asynchronous threads in any suitable manner. The technical solution of this invention does not depend on a specific programming language or framework. The following description uses Java as an example, but those skilled in the art should understand that other languages ​​(such as C++, Go, etc.) can also implement this invention. Exemplarily, the target thread can create an asynchronous thread using the runAsync method of the CompletableFuture class (i.e., an asynchronous task submission method with no return value). The created asynchronous thread can be, for example, a Runnable asynchronous thread.

[0028] Step S12: The asynchronous thread executes the asynchronous call method. In the asynchronous call method, a remote call request is sent to the target server and the system waits to receive the request result returned by the target server. The asynchronous call method is set with a first timeout, which is used to limit the maximum waiting time after sending the remote call request to the target server.

[0029] An asynchronous method call includes at least the following phases: establishing a connection between the client and the server, sending a remote call request from the client to the server, the server processing the request, and the client receiving the server's response. The executed asynchronous method call can correspond to a business request. For example, an asynchronous method call can be executed for a business request for log or other message data. Such requests can include various forms such as user behavior log reporting, business operation log reporting, and message notification pushes. The asynchronous method call executes in an asynchronous thread, meaning it executes asynchronously relative to the target thread. The "asynchronous" aspect of the asynchronous method call refers to the asynchronous thread; for example, while executing the asynchronous method in an asynchronous thread and waiting to receive the response from the target server, the asynchronous thread itself can remain unblocked.

[0030] The client can send a remote call request to the target server based on a business request. The target server can execute the processing operation corresponding to the business request based on the received remote call request, and then return the request result corresponding to the business request to the client.

[0031] For example, the request result can include successful business request execution and business request execution exception. If the request result includes successful business request execution, it indicates that the business process was successful, the business request is complete, and the remote call chain can terminate normally. If the request result includes business request execution exception, it indicates that the business process encountered an error, such as insufficient balance or insufficient inventory, causing the business request to fail to complete and resulting in an error. In this case, subsequent exception handling logic can be executed, such as triggering alarms and logging failures.

[0032] The first timeout period begins when the client sends a remote call request to the target server and starts waiting to receive the response from the target server. If the client does not receive the response from the target server after the first timeout period, the remote call is considered to have timed out. In asynchronous call methods, the first timeout period can be set using gRPC's native timeout mechanism. As mentioned above, the first timeout period does not take effect during the connection establishment phase of the asynchronous call method.

[0033] Step S13: Starting from the creation of an asynchronous thread by the target thread, the target thread waits to obtain the execution result of the asynchronously called method. If the execution result is not obtained after the second timeout period, the remote call is determined to have timed out. The execution result is generated based on the return status of the request result within the first timeout period, and the second timeout period is equal to the first timeout period.

[0034] The execution result generated based on the return status of the request within the first timeout period can include either a successful remote call or a remote call exception. Specifically, if the client receives the request result returned by the target server within the first timeout period, and the request result includes successful execution of the business request, then the execution result can include a successful remote call. If the client receives the request result returned by the target server within the first timeout period, and the request result includes an exception to the business request execution, then the execution result can include a remote call exception. If the client does not receive the request result returned by the target server, no execution result is generated.

[0035] Taking the example of an asynchronous thread generating the execution result, if the client does not receive the request result returned by the target server, it can be assumed that the asynchronous method call has not yet completed execution. In this case, the asynchronous thread will not generate an execution result. Adding a time limit, i.e., adding a waiting time (e.g., a second timeout), allows us to determine the remote call timeout based on this waiting time. The first timeout starts from the client issuing the remote call request. The criterion for timeout using the first timeout is whether the client receives the request result returned by the target server within the first timeout period. If the client does not receive the request result returned by the target server within the first timeout period, the remote call has timed out. The second timeout starts from the creation of the asynchronous thread by the target thread. The criterion for timeout using the second timeout is whether the target thread obtains the execution result of the asynchronous method call within the asynchronous thread within the second timeout period. If the target thread does not obtain the execution result of the asynchronous thread within the second timeout period, the remote call has timed out. The execution result here is based on the return status of the request result. If the client receives the request result returned by the target server, the asynchronous thread generates an execution result; if the client does not receive the request result returned by the target server, the asynchronous thread does not generate an execution result. Therefore, the second timeout is equivalent to monitoring the timeout of the entire asynchronous thread, thus avoiding the problem of the first timeout not taking effect during the connection establishment phase. Moreover, when using the second timeout for timeout judgment, the execution result is based on the return status of the request result, which is actually equivalent to monitoring the execution status of the asynchronous call method executed in the asynchronous thread.

[0036] While the target thread waits to obtain the execution result of the asynchronously invoked method, it can obtain the result in any suitable manner. For example, since the asynchronously invoked method executes in an asynchronous thread, the target thread can obtain the execution result using a result retrieval method corresponding to the method used when creating the asynchronous thread.

[0037] For example, when the target thread creates an asynchronous thread using the `runAsync` method of the `CompletableFuture` class, a `CompletableFuture` object is generated synchronously. This `CompletableFuture` object can be used to receive the execution result of the asynchronous task within the asynchronous thread. Specifically, if the asynchronous thread executes an asynchronous method call without a return value, it can wait in an asynchronous result container to receive the request result returned by the target server. Based on the return information of the request result within the asynchronous result container, an execution result can be generated. The `CompletableFuture` object can receive this execution result, thus enabling the target thread to obtain the execution result of the asynchronous method call within the asynchronous thread. This will be described in detail later with specific examples.

[0038] If the target thread fails to obtain an execution result within the second timeout period, it indicates that the execution result has not yet been generated, meaning the client has not received the requested result from the target server within the second timeout period. If no execution result is obtained within the second timeout period, it means the execution result has still not been generated within the second timeout period, meaning the client has not received the requested result from the target server within the second timeout period, thus confirming a remote call timeout. It is understandable that after a remote call timeout is confirmed, subsequent timeout handling logic can be executed, which will be described in detail later with specific embodiments.

[0039] The second timeout period begins when the target thread creates the asynchronous thread. Therefore, the starting point of the second timeout period differs from that of the first timeout period. For example, the second timeout period can be used to monitor the timeout during the connection establishment phase of an asynchronous call method. The second timeout period can be used to monitor the entire process of the asynchronous call method executed in the asynchronous thread. By setting the second timeout period to an appropriate duration as needed, it can be ensured that the processing result of the business request can be obtained within at most the second timeout period. The processing result of the business request can include successful processing, abnormal processing, and timeout. The processing result of the business request can correspond to the target thread obtaining the execution result. If the target thread obtains the execution result within the second timeout period and the result is a successful remote call, the processing result of the business request is successful. If the target thread obtains the execution result within the second timeout period and the result is an abnormal remote call, the processing result of the business request is abnormal. If the target thread does not obtain the execution result after the second timeout period, it is determined that the remote call has timed out, and the processing result of the business request is timeout.

[0040] When the second timeout is longer than the first timeout, the target thread waits for the result of the asynchronous call within the second timeout period. This is equivalent to obtaining the processing result of the business request within the second timeout period, and the total time elapsed is still longer than the first timeout. For example, if a problem occurs during the connection establishment phase of the asynchronous call, the user's waiting time will still be longer than the first timeout, failing to resolve the issue of the first timeout not taking effect. When the second timeout is shorter than the first timeout, the asynchronous call may still be executing while the remote call has already timed out based on the second timeout, resulting in wasted resources. Therefore, the second timeout can be equal to the first timeout. Setting the second timeout to be equal to the first timeout allows for timeout monitoring of the entire process of the asynchronous call executed in the asynchronous thread. In other words, the second timeout can at least monitor the timeout during the connection establishment phase of the asynchronous call. If the target thread does not obtain the execution result within the second timeout period, the remote call is determined to have timed out, thus avoiding the problem of the first timeout not taking effect when a problem occurs during the connection establishment phase.

[0041] The target thread can set a second timeout in any suitable way. For example, when the target thread creates an asynchronous thread using the runAsync method of the CompletableFuture class, it can set the execution time of the asynchronous thread to the second timeout using the orTimeout method of the CompletableFuture class. In this way, at most after the second timeout period, the asynchronous thread will be forcibly terminated, and the remote call will be determined to have timed out.

[0042] Step S14: The target thread executes the first failure callback method when the remote call times out.

[0043] For example, in the first failure callback method, the target server for the remote call timeout can be changed, that is, a new server can be selected as the target server, and the remote call request can be resent to the target server. When selecting a new server, the distributed server can select a new specified server as the next server, or the client can automatically select a new server as the next server; this application does not limit this.

[0044] In the timeout handling method provided by this invention, an asynchronous thread is created by the target thread, and an asynchronous method is executed within the asynchronous thread. Starting from the creation of the asynchronous thread, the target thread waits for the execution result of the asynchronous method within a second timeout period. If no execution result is obtained after the second timeout period, it indicates that the client has not received the requested result returned by the target server, thus determining a remote call timeout. The starting point of the second timeout period is the moment the target thread creates the asynchronous thread. Therefore, the second timeout period can at least cover the connection establishment phase of the asynchronous method executed by the asynchronous thread. This avoids the problem that the first timeout set in the asynchronous method is ineffective during the connection establishment phase, thereby ensuring that the actual waiting time during the remote call does not exceed the second timeout period. Furthermore, since the second timeout period is equal to the first timeout period, it ensures that the actual time consumed by the remote call process will not exceed the timeout period set by the program. For example, it can ensure that the actual time consumed by the business gRPC client calling the server will not exceed the timeout period set by the program. Determining the remote call timeout using a second timeout period avoids the problem of preset timeouts becoming invalid, ensures more accurate timeout determination, facilitates subsequent timeout exception handling logic, improves overall stability, and helps avoid the risk of cascading failures due to a backlog of business requests. Furthermore, the timeout handling method does not alter the source code of the asynchronous call method, making it easier to implement.

[0045] For example, see Figure 2 ,exist Figure 2In the illustrated embodiment, the target thread can be the main thread. In the asynchronous call method, an asynchronous result container waits to receive the request result returned by the target server. The asynchronous result container has a first callback interface, which listens to the asynchronous result container and generates an execution result based on the return status of the request result within the asynchronous result container. For example, an asynchronous call method can be executed for business requests for message data such as logs. These requests can include various forms such as user behavior log reporting, business operation log reporting, and message notification pushes. For example, the asynchronous call method can have an asynchronous result container. The target thread can create an asynchronous thread using the `runAsync` method of the `CompletableFuture` class. When this asynchronous thread executes the asynchronous call method, it can wait to receive the request result returned by the target server through the asynchronous result container. For example, in the asynchronous call method, the client sends a remote call request to the target server. The target server can immediately return an asynchronous result container (e.g., immediately return a `ListenableFuture` object). When the target server completes processing and returns the request result, the request result can be returned to the asynchronous result container. The asynchronous result container has a first callback interface, through which callback logic can be registered. This first callback interface can be, for example, a FutureCallback interface, through which callback logic can be registered. Based on the registered callback logic, the first callback interface listens for a response from the asynchronous result container. When a request result is returned to the container, the first callback interface generates a corresponding execution result based on the returned request result. For example, for a successful business request, it can generate a successful remote call execution result; for an abnormal business request, it can generate an abnormal remote call execution result. If the asynchronous result container does not receive a returned request result, it does not generate an execution result.

[0046] In this timeout handling method, the asynchronous thread executes the asynchronous method call. Asynchronous method calls are more suitable for business requests involving log and other message data, such as user behavior log reporting, business operation log reporting, and message notification pushes. Therefore, this timeout handling method is more suitable for business requests involving log and other message data. When the asynchronous thread executes the asynchronous method call, it does not block while the asynchronous result container waits to receive the request result from the target server, avoiding continuous occupation of thread resources and improving the system's concurrent processing capabilities.

[0047] For example, the target thread waits to obtain the execution result of the asynchronously called method. If the execution result is not obtained after the second timeout period, the remote call is determined to have timed out. This includes: the target thread listening for the execution result through a second callback interface, and determining that the remote call has timed out if the execution result is not obtained after the second timeout period through the second callback interface; and determining that the remote call has not timed out if the execution result is obtained within the second timeout period. For example, a second callback interface can be set for the asynchronous task executed by the asynchronous thread. Specifically, a second callback interface can be set for the asynchronous task object (e.g., a CompletableFuture object). Through the second callback interface, it is possible to listen for whether the asynchronous thread generates an execution result, thus realizing the listening for the execution result through the second callback interface. When the target thread does not obtain the execution result after the second timeout period, it means that the asynchronous thread has not generated an execution result after the second timeout period. That is, in the asynchronously called method executed by the asynchronous thread, the client has not received the request result returned by the target server after the first timeout period, therefore, the remote call is determined to have timed out. When the target thread obtains the execution result within the second timeout period, it indicates that the asynchronous thread generated an execution result within that timeout period. In other words, within the asynchronous call method executed by the asynchronous thread, the client received the request result returned by the target server within the second timeout period. Since the start date of the second timeout period is synchronized with or before the start date of the first timeout period, it can also be determined that the client received the request result returned by the target server within the first timeout period. Therefore, it is confirmed that the remote call did not time out. The target thread can listen for the execution result through the second callback interface, thus avoiding blocking and waiting for the result, preventing continuous occupation of thread resources.

[0048] For example, generating an execution result based on the return status of a request result within the asynchronous result container includes: if the asynchronous result container has a request result returned within a first timeout period, then executing a first success callback method to obtain the execution result; in the first success callback method, if the request result is normal, generating an execution result indicating that the remote call was normal; if the request result is abnormal, generating an execution result indicating that the remote call was abnormal; the timeout handling method further includes: if the asynchronous result container does not have a request result returned within the first timeout period, then executing a second failure callback method; in the second failure callback method, switching the target server from the current server to the next server. Callback logic can be registered through the first callback interface, and the callback logic can include the first success callback method and the second failure callback method. Taking the asynchronous result container as a ListenableFuture object and the first callback interface as a FutureCallback callback interface as an example, the FutureCallback callback interface can set a first success callback method and a second failure callback method. The first success callback method can be, for example, the onSuccess method, and executing the onSuccess method will obtain the execution result. In this context, if the ListenableFuture object receives a normal request result (i.e., the request result corresponds to a successful execution of the business request), executing the onSuccess method will retrieve the successful execution result of the remote call. If the ListenableFuture object receives an abnormal request result (i.e., the request result corresponds to an abnormal execution of the business request), executing the onSuccess method will retrieve the abnormal execution result of the remote call. The second failure callback method can be, for example, the onFailure method. Executing the onFailure method switches the target server from the current server to the next server, meaning that retries can be implemented to other nodes within the onFailure method. If the asynchronous result container does not return a request result within the first timeout period, the second failure callback method is executed. For example, in the case of a remote call timeout, the second failure callback method is executed, switching the target server from the current server to the next server, enabling retries to other nodes, thus achieving rapid fault recovery and avoiding data loss and remote call chain anomalies. For example, the request result received by the ListenableFuture object can have a business code value (e.g., a code value), which can be used to determine whether the business request was successful or failed. In this case, if the ListenableFuture object receives a normal request result, meaning the request result corresponds to the successful execution of the business request, the asynchronous thread can exit normally.When the ListenableFuture object receives an abnormal request result, it executes the first success callback method instead of retrying to other nodes. This is because an abnormal request result corresponds to an abnormal execution of the business request, which may not be resolved by retrying to other nodes. For example, for business request execution errors caused by insufficient balance or insufficient inventory, the first success callback method, after obtaining the execution result of the remote call error, can, for example, issue an alarm for the abnormal execution of the business request.

[0049] For example, the target thread waits to obtain the execution result of the asynchronous method call. If the execution result is not obtained after a second timeout period, the remote call is determined to have timed out. This includes: the target thread listening for the execution result through a second callback interface, and determining that the remote call has timed out if the execution result is not obtained after the second timeout period through the second callback interface; and determining that the remote call has not timed out if the execution result is obtained within the second timeout period. The timeout handling method further includes: if the execution result indicates that the remote call is normal when the remote call has not timed out, the target thread executes a second success callback method through the second callback interface; if the execution result indicates that the remote call is abnormal, the first failure callback method is executed. Executing the first failure callback method when the remote call times out includes: the target thread executing the first failure callback method when the remote call times out through the second callback interface. The second success callback method is used to determine that the asynchronous method call has been successfully executed and exit the asynchronous thread, and the first failure callback method is used to switch the target server from the current server to the next server. Callback logic can be registered through the second callback interface, and the callback logic can include the second success callback method and the first failure callback method. If the remote call does not time out, the second callback interface obtains an execution result. This result corresponds to a successful remote call, meaning the client receives a successful response from the target server, in which case the second success callback method can be executed. If the result corresponds to an exception in the remote call, meaning the client receives a failed response from the target server, in which case the first failure callback method can be executed. If the remote call times out, the second callback interface does not obtain an execution result, in which case the first failure callback method can be executed.

[0050] The second success callback method could be, for example, the `thenRun` method. The `thenRun` method can set a successful remote call label (e.g., a `Success` label) and then execute normally before the thread exits. The first failure callback method could be, for example, the `exceptionally` method. The `exceptionally` method can retry to other nodes. For instance, when executing the `exceptionally` method, the `onFailure` method can be further executed to trigger retrying to other nodes. Executing the first failure callback method when a remote call times out enables rapid disaster recovery and avoids business processing failures caused by abnormal remote call chain conditions. Determining a remote call timeout based on the second timeout period enables fast failure, i.e., rapid circuit breaking of the remote call chain, thereby quickly releasing thread resources and avoiding excessive thread resource consumption. Furthermore, executing the first failure callback method when a remote call times out to retry to other nodes ensures that business requests can continue to attempt processing and that chain data logs are not lost.

[0051] For example, in the second failure callback method or the first failure callback method, the next server is specified by the distributed server, or the next server is automatically selected.

[0052] When specifying the next server through a distributed server, a pre-defined switching strategy can be used to select a server from the service cluster as the next server. When specifying the next server through a distributed server, the client only needs to passively receive and execute the switch, which reduces client complexity and facilitates lightweight deployment.

[0053] When automatically selecting the next server, the client can choose from multiple servers autonomously. This eliminates the need for the client to wait for the distributed server to specify the next server, thus reducing the time required for timeout processing.

[0054] For example, the target thread has a countdown counter initially set to 1. The first failure callback method also resets the countdown counter to 0 to release the asynchronous thread. The countdown counter can be set, for example, using the CountDownLatch utility class. For instance, the countdown counter can be set by creating a CountDownLatch object on the target thread. The first failure callback method can initiate a retry to another node if the remote call times out. If the retry to another node occurs and the remote call does not time out, the first failure callback method can reset the countdown counter to 0 to release the asynchronous thread. This timeout handling method allows for timely release of thread resources, avoiding excessive thread resource consumption and facilitating memory resource release.

[0055] According to another aspect of the invention, see Figure 3 A timeout processing device 300 is provided, comprising:

[0056] Create module 310 to respond to business requests by creating an asynchronous thread from the target thread;

[0057] Execution module 320 is used to execute an asynchronous call method by an asynchronous thread. In the asynchronous call method, a remote call request is sent to the target server and the system waits to receive the request result returned by the target server. The asynchronous call method has a first timeout period, which limits the maximum waiting time after sending the remote call request to the target server.

[0058] The determination module 330 is used to start from the creation of an asynchronous thread by the target thread, and the target thread waits to obtain the execution result of the asynchronous call method. If the execution result is not obtained after the second timeout period, the remote call timeout is determined. The execution result is generated based on the return status of the request result within the first timeout period, and the second timeout period is equal to the first timeout period.

[0059] According to another aspect of the invention, see Figure 4 An electronic device 400 is provided. The electronic device 400 includes a processor 410 and a memory 420. The memory 420 stores computer program instructions, which are executed by the processor 410 to perform any of the timeout handling methods described above.

[0060] According to another aspect of the present invention, a storage medium is provided on which program instructions are stored, which, when executed, are used to perform any of the timeout handling methods described above.

[0061] According to another aspect of the present invention, a computer program product is provided, comprising computer program instructions that, when executed, perform any of the timeout handling methods described above.

[0062] Those skilled in the art can understand the specific implementation and beneficial effects of the above-described timeout handling method, electronic device, storage medium, and computer program product by reading the detailed description of the timeout handling method above, and for the sake of brevity, they will not be described in detail here.

[0063] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of the invention. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention. All such changes and modifications are intended to be included within the scope of the invention as claimed in the appended claims.

[0064] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0065] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0066] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0067] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the description of exemplary embodiments of the invention. However, this approach should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, its inventive point lies in solving the corresponding technical problem with fewer features than all of those in a single disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0068] Those skilled in the art will understand that, apart from the mutual exclusion of features, all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or elements of any method or apparatus so disclosed may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0069] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the claims, any of the claimed embodiments can be used in any combination.

[0070] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules according to the embodiments of the present invention. The present invention can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0071] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0072] The above are merely specific embodiments or descriptions of the present invention, and the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method of handling timeouts, characterized by, The timeout handling method includes: In response to a business request, an asynchronous thread is created by the target thread; The asynchronous thread executes the asynchronous call method, in which a remote call request is sent to the target server and the server waits to receive the request result returned by the target server. The asynchronous call method is set with a first timeout, which is used to limit the maximum waiting time after the remote call request is sent to the target server. Starting from the creation of the asynchronous thread by the target thread, the target thread waits to obtain the execution result of the asynchronous call method. If the execution result is not obtained after the second timeout period, the remote call is determined to have timed out. The execution result is generated based on the return status of the request result within the first timeout period, and the second timeout period is equal to the first timeout period. The target thread executes the first failure callback method when the remote call times out.

2. The timeout handling method according to claim 1, characterized in that, In the asynchronous call method, an asynchronous result container waits to receive the request result returned by the target server. The asynchronous result container is equipped with a first callback interface, which is used to listen to the asynchronous result container and generate the execution result based on the return status of the request result in the asynchronous result container.

3. The timeout handling method according to claim 2, characterized in that, The process of the target thread waiting to obtain the execution result of the asynchronously called method, and determining that the remote call has timed out if the execution result is not obtained after a second timeout period, includes: The target thread listens for the execution result through the second callback interface, and determines that the remote call has timed out if the execution result is not obtained after the second timeout period, and determines that the remote call has not timed out if the execution result is obtained within the second timeout period.

4. The timeout handling method according to claim 2, characterized in that, Generating the execution result based on the return information of the request result within the asynchronous result container includes: If the asynchronous result container has the request result returned within the first timeout period, then the first success callback method is executed to obtain the execution result; In the first success callback method, if the request result is normal, an execution result is generated to indicate that the remote call is normal; if the request result is abnormal, an execution result is generated to indicate that the remote call is abnormal. The timeout handling method further includes: If the asynchronous result container does not have the request result returned within the first timeout period, then the second failure callback method is executed; In the second failure callback method, the target server is switched from the current server to the next server.

5. The timeout handling method according to claim 4, characterized in that, The process of the target thread waiting to obtain the execution result of the asynchronously called method, and determining that the remote call has timed out if the execution result is not obtained after a second timeout period, includes: The target thread listens for the execution result through the second callback interface, and determines that the remote call has timed out if the execution result is not obtained after the second timeout period, and determines that the remote call has not timed out if the execution result is obtained within the second timeout period. The timeout handling method further includes: If the execution result indicates that the remote call is normal, the second success callback method is executed when the remote call is not timed out by the target thread through the second callback interface; if the execution result indicates that the remote call is abnormal, the first failure callback method is executed. The method for executing the first failure callback when the remote call times out by the target thread includes: The target thread executes the first failure callback method when the remote call times out via the second callback interface; The second success callback method is used to determine that the asynchronous call method has been successfully executed and to exit the asynchronous thread, while the first failure callback method is used to switch the target server from the current server to the next server.

6. The timeout handling method according to claim 4 or 5, characterized in that, In either the second failure callback method or the first failure callback method The next server is specified through a distributed server. Alternatively, the next server can be selected automatically.

7. The timeout handling method according to claim 5, characterized in that, The target thread is equipped with a countdown counter, which is initially set to 1. The first failure callback method is also used to reset the countdown counter to 0 in order to release the asynchronous thread.

8. An electronic device comprising a processor and a memory, characterized in that, The memory stores computer program instructions, which, when executed by the processor, are used to perform the timeout handling method as described in any one of claims 1-7.

9. A storage medium on which program instructions are stored, characterized in that, The program instructions are used to execute the timeout handling method as described in any one of claims 1-7 when the program is run.

10. A computer program product comprising computer program instructions, characterized in that, The computer program instructions are used to execute the timeout handling method as described in any one of claims 1-7 when the program is run.

Images