Request retry method and device

Abstract

The invention discloses a request retry method and device, and relates to the technical field of computers. A specific embodiment of the method comprises the following steps: when a response result of a first request indicates failure, judging whether retry can be carried out or not according to the current number of times of retry of the first request; if so, determining the number of second requests which are retried at present; if the number of the second requests is smaller than the maximum number of retry requests, performing retry after the retry waiting time is delayed, otherwise, performing retry after the retry of one second request is finished, and delaying the retry waiting time for retry, wherein the retry waiting time is calculated based on a preset initial waiting time interval and the current number of retry times of the first request. According to the implementation mode, the number of retry requests can be limited, limited times of retry can be executed on each request, the optimal time delay of the retry can be judged, excessive invalid retry is avoided, immersive modification of codes and decoupling of retry logic and normal logic do not need to be conducted, and retry is conducted in a simple, elegant and reusable mode when a front-end calling interface fails.

Description

technical field [0001] The present invention relates to the field of computer technology, in particular to a method and device for request retry. Background technique [0002] In the application, it is often necessary to implement the following functions: upload data to the remote storage service or pull the required data from the remote storage service, and do other operations in the case of a successful response. This function can be simply divided into two steps: call the remote service logic package to return the processing result to the processing method; implement the retry upload logic based on the processing result of the previous step or catch the exception, otherwise continue the logical operation. When the dependent interface returns a system exception due to internal errors or other errors, the retry mechanism is particularly important, otherwise manual operations are required to call again. [0003] At present, there are several schemes for the front-end ajax (...

AI Technical Summary

Problems solved by technology

[0005] Both scheme 1 and scheme 2 cannot limit the number of retry requests, and cannot execute retries elegantly and effectively. Moreover, when the interface relied on by scheme 1 has not recovered from the network exception, subsequent retries will fail, resulting in the execution of There are many invalid retries, and the intrusive modification of the code directly fails to realize the decoupling of retry logic and normal logic. Solution 2 cannot judge the best time for delay, and still cannot avoid more invalid retries

Images