CN110929202B - Page request failure processing method and device and computer equipment - Google Patents
Page request failure processing method and device and computer equipment Download PDFInfo
- Publication number
- CN110929202B CN110929202B CN201811099007.8A CN201811099007A CN110929202B CN 110929202 B CN110929202 B CN 110929202B CN 201811099007 A CN201811099007 A CN 201811099007A CN 110929202 B CN110929202 B CN 110929202B
- Authority
- CN
- China
- Prior art keywords
- request
- page
- failure type
- failure
- retry
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
Abstract
The invention discloses a page request failure processing method, a device and computer equipment, wherein a large number of page requests with failed requests are divided into a plurality of failure types in advance, request retry logic is not configured for each failure type, so that the page requests with multiple failed requests corresponding to the failure types can call the request retry logic to resend the page requests with failed requests, specifically, whether the state information of the page requests with failed requests is matched with the failure types configured in advance is judged to detect whether the page requests with failed requests can call the universal request retry logic configured in advance or not, and if the judgment result is yes, the universal request retry logic configured in advance is called to realize resending of the page requests with failed requests, the request retry logic required by the page requests does not need to be configured manually one by one, the configuration workload of the request retry logic is greatly reduced, and the processing efficiency of the failed page requests is improved.
Description
Technical Field
The invention relates to the technical field of data processing, in particular to a page request failure processing method, a page request failure processing device and computer equipment.
Background
Nowadays, people's aspects such as life, work have not left the internet, no matter be individual, enterprise, school or other units etc. can all use network to publish latest developments to make network information all can update anytime and anywhere, the user can obtain latest dynamic information through refreshing current page.
In order to improve the page refreshing efficiency And avoid repeatedly loading the same page content, the partial refreshing of the page is usually realized by using an AJAX (Asynchronous JavaScript And XML) technology at present, which is a technology for creating a fast dynamic web page, and the page Asynchronous updating can be realized by performing a small amount of data interaction with a server at the background, that is, partial content of the page is updated without reloading the content of the whole page.
In order to implement the local refresh of the page, if the request is overtime or the login authentication information is expired, the page request often fails, the user needs to configure a corresponding request retry logic, add the request retry logic to a corresponding failure processing function, add the retry logic, and execute the retry logic after the reason causing the request failure is solved, so as to implement the local refresh of the page.
Therefore, in the existing page request failure processing method, retry logic needs to be manually added every request failure, which is relatively complicated, and the local page refreshing efficiency is reduced.
Disclosure of Invention
In view of the above, the present invention is proposed to provide a page request failure processing method, apparatus and computer device that overcome the above problems or at least partially solve the above problems.
The embodiment of the invention provides a page request failure processing method, which comprises the following steps:
monitoring the state information of each page request with failed request;
judging whether the state information is matched with a preset failure type;
if so, calling a request retry logic corresponding to the preconfigured failure type matched with the state information according to the corresponding relation between the preconfigured failure type and the request retry logic;
executing the invoked request retry logic to resend the page request for which the request failed.
Optionally, the determining whether the state information matches a preconfigured failure type includes:
determining the failure type of the page request with failed request according to the state information;
and judging whether the failure type of the page request exists in the pre-configured failure types.
Optionally, the determining whether the state information matches a preconfigured failure type includes:
and inquiring whether the state information of the page request exists from the state information matched with the preconfigured failure type.
Optionally, the method further includes:
under the condition that the judgment result is negative, outputting configuration prompt information;
and the configuration prompt message is used for reminding a user of the page request configuration request retry logic which fails to request.
Optionally, the invoking a request retry logic corresponding to a preconfigured failure type that is matched with the state information includes:
judging whether a preconfigured failure type matched with the state information is a first failure type, wherein the first failure type is a failure type of a preset manual trigger request retry logic;
if yes, receiving a retry instruction generated based on user trigger operation, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
and if not, generating a retry instruction, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information.
Optionally, after resending the page request for which the request fails, the method further includes:
determining that the retransmitted page request fails, and acquiring the current retry times of the page request;
judging whether the current retry times reach preset times or not;
if so, deleting the page request;
if not, the request retry logic execution continues to be triggered, and until the retry times of the page request reach the preset times, or request data of the page request are received.
Optionally, the method further includes:
acquiring all page requests initiated aiming at a target page;
determining a failure type corresponding to failure of each page request, and taking the failure types of the page requests corresponding to a plurality of request failures as failure types configured in advance;
acquiring a request retry logic configured for each preconfigured failure type, and establishing a corresponding relation between the request retry logic and the preconfigured failure types.
Optionally, the method further includes:
inserting the called request retry logic into a failure handling function of the page request with a failed request;
the request retry logic of the execution call comprising:
the failure handling function is executed.
The embodiment of the invention also provides a device for processing the page request failure, which comprises:
the state monitoring module is used for monitoring the state information of the page request with failed request;
the state judgment module is used for judging whether the state information is matched with a preset failure type;
a request retry logic calling module, configured to, if the determination result of the state determination module is yes, call a request retry logic corresponding to a preconfigured failure type that matches the state information according to a correspondence between the preconfigured failure type and the request retry logic;
a request retry logic execution module to execute the invoked request retry logic to resend the page request for which the request failed.
An embodiment of the present invention further provides a computer device, where the computer device includes:
a communication interface;
a memory for storing a program for implementing the page request failure processing method as described above;
a processor for loading and executing the memory-stored program, the program for:
monitoring the state information of the page request with failed request;
judging whether the state information is matched with a preset failure type;
if so, calling a request retry logic corresponding to the preconfigured failure type matched with the state information according to the corresponding relation between the preconfigured failure type and the request retry logic;
executing the invoked request retry logic to resend the page request for which the request failed.
By means of the technical scheme, the page request failure processing method provided by the invention is characterized in that at least one failure type of page request failure is predetermined, and the request retry logic corresponding to each failure type is configured, so that after the state information of the page request with the failure request is monitored, whether the page request is matched with the failure type configured in advance can be judged firstly, if the page request is matched with the failure type configured in advance, the request retry logic corresponding to the matched failure type configured in advance is directly called, the request retry logic of the page request does not need to be written manually, and for a plurality of page requests with the failure request matched with the failure type configured in advance, the request retry logic called by the embodiment belongs to the universal request retry logic.
The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
fig. 1 is a flowchart illustrating a page request failure processing method according to an embodiment of the present invention;
fig. 2 is a schematic flowchart illustrating another page request failure processing method according to an embodiment of the present invention;
fig. 3 is a flowchart illustrating a further page request failure processing method according to an embodiment of the present invention;
fig. 4a is a schematic flowchart illustrating a further page request failure processing method according to an embodiment of the present invention;
fig. 4b is a flowchart illustrating a further page request failure processing method according to an embodiment of the present invention;
fig. 5 is a flowchart illustrating a further page request failure processing method according to an embodiment of the present invention;
fig. 6 is a schematic structural diagram illustrating a page request failure processing apparatus according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram illustrating another page request failure processing apparatus according to an embodiment of the present invention;
fig. 8 is a schematic structural diagram illustrating a further page request failure processing apparatus according to an embodiment of the present invention;
fig. 9 is a schematic structural diagram illustrating a further page request failure processing apparatus according to an embodiment of the present invention;
fig. 10 is a schematic structural diagram illustrating still another page request failure processing apparatus according to an embodiment of the present invention;
fig. 11 is a schematic diagram illustrating a hardware structure of a computer device according to an embodiment of the present invention;
fig. 12 is a flowchart illustrating a page request failure processing method according to an embodiment of the present invention.
Detailed Description
In view of the problems of the prior art as set forth in the background section, the inventors of the present invention propose: the method and the device adopt the universal request retry logic to realize the resending of the failed page requests, do not need to configure the corresponding request retry logic aiming at each failed page request, and face hundreds of page requests corresponding to the pages, thereby greatly reducing the workload of configuring the request retry logic, improving the processing efficiency of the page request failure and further improving the response efficiency of the page request.
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
Referring to fig. 1, a flowchart of a page request failure processing method provided in an embodiment of the present invention is schematically illustrated, where the method may be applied to a computer device, and specifically may include, but is not limited to, the following steps:
s11, monitoring the state information of the page request with failed request;
the page request related to this embodiment may be an AJAX request, which is an asynchronous request, that is, the browser gives the page request to a proxy object-XMLHttpRequest (the proxy object is built in most browsers), the proxy object initiates the page request to the server, receives and analyzes data responded by the server, and updates the data to a control specified by the browser, thereby implementing local refresh of the page data. The present embodiment does not describe in detail how the page request is generated.
In practical application, after the generated page request is sent to the server, the state of the page request may be monitored, such as page request initialization, received page request, in page request processing, completed page request and ready response, page request failure (e.g., failure caused by page request abnormality), and the like.
Optionally, the page request may actually be an Http request, and the monitored state information indicating the current state of the page request may be a state code, that is, in this embodiment, different state codes may be used to indicate the processing states of the corresponding page request, such as 1 xx-response and 2 xx-success, that is, the server successfully receives the page request sent by the client and 3 xx-redirection, that is, the client browser needs to adopt more operations to implement the page request, and 4 xx-the client has an error, such as a page where the client request does not exist, and the client does not provide valid authentication information, and the like.
It should be noted that, the content of the status information of the page request is not limited in this embodiment, and is not limited to the status codes listed above.
In addition, the page request failure processing method provided by this embodiment may be applied to Jquery, that is, a lightweight Javascript library, and is compatible with CSS3 and various browsers, and the working process of Jquery in each application scenario is not described in detail in this embodiment.
Step S12, judging whether the state information is matched with a preset failure type;
in the practical application of this embodiment, it is monitored that a page request fails, and state information corresponding to the current time can be acquired, so that whether the failure type of the page request belongs to a failure type configured in advance is determined by using the state information, and if the failure type of the page request belongs to the failure type, it is described that the page request failing this time has the same failure reason as other page requests, and the same request retry logic can be shared; if not, the page request failing the request does not have other page requests with the same failure reason as the page request, and a technician is required to configure the currently required request retry logic.
The preconfigured failure type may be determined by performing a request failure test in advance for all page requests initiated by the current page, as shown in fig. 2, the implementation process may include, but is not limited to, the following steps:
step S21, acquiring all page requests initiated aiming at a target page;
step S22, determining the failure type corresponding to the failure of each page request, and taking the failure type of the page request corresponding to a plurality of request failures as a failure type configured in advance;
in this embodiment, a specific reason for the failure of the page request due to different reasons may be determined as a failure type, and as for the state in which the client has an error as described above, the specific reason may be that the page request fails due to a page that the client does not request, that the client does not provide valid authentication information, or the like, or the page request fails due to a currently used network failure, that the request time exceeds the maximum request time, or the like. Based on different failure reasons, the present embodiment may determine a corresponding failure type, such as timeout, authentication failure, page absence, and the like.
After determining the respective corresponding failure types when all the page requests fail, the number of the page requests corresponding to each failure type can be determined through statistics.
Step S23, obtaining the request retry logic configured for each preconfigured failure type, and establishing a corresponding relationship between the request retry logic and the preconfigured failure type.
In practical applications, each page request (i.e., AJAX request) usually has a success processing function and a failure processing function, when the page request initiated this time succeeds, the attack processing function is executed, if the failure needs to be retried, a specific request processing logic for retrying can be usually added to the failure processing function, and when the current state meets the retry condition, the request retry logic is executed.
Taking a normal AJAX request in Jquery as an example for explanation, as shown in the following program codes, an operation executed in a successful processing function of the AJAX request may also be multiplexed in a retry operation process in a failed processing function:
following the description of the status code above, the code 401 in the above process may indicate that access is denied, which may be a login failure, a login failure due to server configuration, no authorization due to restrictions of resources by an ACL, a filter authorization failure, etc.; 403 may indicate access barring, which may be for reasons such as execution access barred, read access barred, write access barred, IP address denied, client credentials required, site access denied, number of users exceeded, configuration invalid, password change, client credentials revoked, and so forth. 500 may indicate an internal server error, which may specifically be that the application is busy with a restart on the Web server, the Web server is too busy, the gateway times out, the HTTP version is not supported, and the like, and this embodiment does not limit the specific content indicated by the status code.
In the conventional application, if an AJAX request fails, a technician needs to add a corresponding request retry logic in a failure processing function of the AJAX request to resend the AJAX request, which is troublesome, especially if a common page has thousands of AJAX requests, and if the technician configures the corresponding request retry logic one by one, the processing efficiency will be greatly reduced.
In order to improve this situation, the inventor of the present invention knows that the page requests have failed due to the same failure reason, and may reinitiate the page requests according to the general request retry logic, so in order to reduce the workload of the user configuring the request retry logic, this embodiment may configure the request retry logic required by such a type of page request once, and differently configure the request retry logic once for each page request thereof, thereby improving the efficiency of processing the page request failure.
Further, after configuring the general request retry logic, establishing a corresponding relationship between the request retry logic and the corresponding preconfigured failure type, so that each request failed page request corresponding to the preconfigured failure type can directly call the request retry logic corresponding to the preconfigured failure type to resend the request failed page request without configuring the request retry logic one by one.
It should be noted that, in this embodiment, a configuration process of the request retry logic is not described in detail, and it is usually necessary to modify and adjust an original parameter or failure processing logic of the page request (i.e., AJAX request), and the obtained request retry logic may be added to a failure processing function of the page request, so that when a trigger condition of the request retry logic is currently satisfied, the request retry logic is executed.
In addition, the present embodiment does not limit the corresponding relationship between the request retry logic and each preconfigured failure type, and the corresponding relationship between each preconfigured failure type and the status information of the page request that has failed to each request, such as the corresponding relationship table. Based on this, the step S12 may specifically be to query whether the status information of the page request that fails to request exists from the status information that matches the preconfigured failure type, but is not limited to this implementation.
In addition, in practical applications, as analyzed above, the request retry logic is usually not directly executed, and usually the logic of the page request itself (such as the failure handling function) is executed first, and then the request retry logic is executed.
Step S13, under the condition that the judgment result is yes, calling a request retry logic corresponding to the pre-configured failure type matched with the state information according to the corresponding relation between the pre-configured failure type and the request retry logic;
in this embodiment, after determining that the failure type of the page request that fails to receive the current request belongs to a failure type that is configured in advance, the general request retry logic corresponding to the determined failure type that is configured in advance may be invoked. For each request failure page request corresponding to the target failure type, the request failure page request may be sent to an array cache first, and waits to be extracted for retry.
Optionally, in this embodiment, the page request with the request failure may be sent to the globalErrors array cache, and when the retry is needed, the globalErrors array is called, and the page requests cached in the globalErrors array are retried in sequence. In this embodiment, the page requests corresponding to the same failure type of request failure may be cached in one globallerros array, so that each page request cached in the globallerros array directly calls the same request retry logic.
In addition, in this embodiment, a triggering manner for invoking the request retry logic in step S13 is not limited, such as an automatic triggering manner or a manual triggering manner, and according to actual needs, which failure types adopt the automatic triggering manner and which failure types adopt the manual triggering manner may be configured in advance, and a specific implementation manner is not limited.
The automatic triggering mode may be a timing triggering mode, retry the content of the failed page request again, or directly invoke a request retry logic corresponding to the determined page request that fails the current request, and so on.
For this, the present embodiment may pre-configure corresponding codes, establish an association between the codes and a trigger button, and output an interface for the user to select whether to retry after determining the page request that has failed, where the interface may output the page request that has failed to request, and the user may select the page request that needs to be retried currently, and click a "retry" button, thereby triggering the corresponding codes and invoking request retry logic to complete the retry of the page requests selected by the user.
Based on the above analysis, as shown in fig. 3 below, the step S13 may specifically include, but is not limited to, the following steps:
step A1, judging whether a preconfigured failure type matched with the state information is a first failure type, and if so, entering step A2; if not, executing the step A4;
the first failure type may be a failure type corresponding to a page request that needs a user to manually trigger a retry, that is, a failure type of a preset manual trigger request retry logic, and accordingly, the failure type corresponding to an automatic trigger retry page request may be marked as a second failure type.
In addition, the failure type determined in step A1 may be the identified target failure type of the page request corresponding to the multiple request failures, such as timeout, failure in verifying the identity information, and the like.
Step A2, receiving a retry instruction generated based on user trigger operation;
step A3, responding to the retry instruction, and calling a request retry logic corresponding to a preset failure type matched with the state information;
as described above, after determining that the page request fails to be requested, the page request including each failure may be output on the current display interface of the user equipment, so that the user manually triggers the page request to retry, and the specific generation method of the retry instruction in step A2 is not limited in this embodiment.
Step A4, generating a retry instruction, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
as can be seen, if it is determined that a page request corresponding to a request failure requires a manual trigger retry request, a corresponding request retry logic may be manually triggered and invoked in the manner described above; on the contrary, a retry instruction is automatically generated to call a corresponding request retry logic, retry of the page requests with failed requests is realized, retry requirements of various page requests are met, and retry triggering flexibility is improved.
Step S14, the invoked request retry logic is executed to resend the page request for which the request failed.
In combination with the above analysis, after the request retry logic is called, the request retry logic may be inserted into a failure handling function of the current request-failed page request, and accordingly, step S14 may specifically be to execute the failure handling function (which already includes the called request retry logic) to implement resending the request-failed page request, and the retry processes for other request I to fail page requests are similar, and the details of the embodiment are not described herein again.
The contents of the failure processing function related to the page request and the execution method thereof are not limited in this embodiment, and the contents included in the request retry logic are not limited.
In summary, in the present embodiment, by monitoring the state information of the page request with a failed request, the preconfigured failure type to which the state information belongs is determined first, and the request retry logic corresponding to the preconfigured failure type is directly called by using the correspondence between the preconfigured failure type and the request retry logic, so as to implement resending of the page request with a failed request, without manually configuring the request retry logic required this time, and improve the processing efficiency.
Optionally, in this embodiment, a program for implementing the page request failure processing method described in the above embodiment may be configured in the function in a manner of extending an ajaxError function carried by the Jquery, specifically, the page request failure processing method may be implemented by using a Jquery plug-in, where the Jquery plug-in is a UI component developed to extend a function library of the Jquery or according to a requirement of the Jquery plug-in, and how to implement the extension of the Jquery by using the Jquery plug-in is not described in detail in this embodiment, so that a specific implementation of the page request failure processing method described in the above embodiment is implemented.
In the ajaxError function, the page requests of which the acquired HTTP state codes are consistent with the preset failure types can be judged, and the page requests are put into the globallerrors array of the Jquery plugin for caching, so that the page requests can be sequentially extracted from the globallerrors array for retrying when the subsequent trigger requests are retryed.
As another embodiment of the present invention, on the basis of the above embodiments, the step S12 may be implemented in, but not limited to, the following two ways:
the first method is as follows: as shown in the flowchart of fig. 4a, the process of obtaining the status information of the page request with a failed request may refer to the description of the corresponding part in the foregoing embodiment, which is not repeated herein, and this embodiment mainly describes the implementation process of step S12 in the foregoing embodiment, and the steps are as follows:
b1, acquiring each state information matched with a preset failure type;
b2, inquiring whether the state information of the page request with the failed request exists in the acquired state information, and if so, entering the step B3; if not, executing the step B4;
for the specific detection method in step B1, reference may be made to the description of the preconfigured target failure type and the identification process thereof in the foregoing embodiment, and details are not described herein in this embodiment.
Step B3, marking the state information and the preset failure type as a target failure type;
it should be noted that, in the present embodiment, when the determination result in the step B2 is yes, the step of invoking the request retry logic in the step S13 and the step of executing the step S14 may be directly executed, which is not described herein again.
Step B4, outputting prompt information of configuration request retry logic;
in combination with the foregoing analysis, if the page request that fails to be requested does not have other page requests with the same failure reason as the page request, that is, the failure type of the page request that fails to be requested does not belong to the pre-configured failure type, a technician is required to configure the request retry logic for the page request alone, at this time, corresponding prompt information may be output to prompt the user to perform configuration of the request retry logic, and the content included in the prompt information and the output mode thereof are not limited in this embodiment.
Optionally, in this embodiment, a corresponding request retry logic may also be configured in advance for the page request with the failed request according to the implementation manner of the preconfigured failure type, so that, if the determination result in step B2 is negative, the request retry logic configured for the page request may be directly invoked, and the request retry logic is executed, so as to implement retry of the page request.
And step B5, acquiring target request retry logic configured for the page request with the request failure, and executing the target request retry logic to resend the page request with the request failure.
The second method comprises the following steps: as shown in the flowchart of fig. 4b, step S12 in the above embodiment can also be implemented according to the following method:
step C1, determining the current failure type of the corresponding page request by using the state information of each page request;
step C2, acquiring at least one failure type configured in advance;
the preset at least one failure type is the target failure type described above, and according to needs, this embodiment may further divide which failure types need to automatically trigger a retry logic, which failure types need to manually trigger the retry logic, and so on.
C3, judging whether the current failure type belongs to any one of the preset failure types, and if so, entering the step C4; if not, executing the step C5;
step C4, marking the current failure type as a target failure type;
in this embodiment, when the determination result in the step C3 is yes, the step of invoking the retry request logic in the step S13 and the step of executing the step S14 may be directly executed, which is not described herein again. And C5, outputting configuration prompt information.
And the configuration prompt message is used for reminding a user of configuring corresponding request retry logic for the page request corresponding to the current failure type. Regarding the steps after configuring the request retry logic, reference may be made to the description of a corresponding part of the above-mentioned manner, and details are not described again in this embodiment.
Of course, this embodiment may also be configured with corresponding request retry logic in advance for a page request that cannot use the universal request retry logic, and if the determination result in the step C3 is no, the preconfigured corresponding request retry logic may be directly invoked, which is not limited to the online configuration described in this embodiment.
It can be seen that, in this embodiment, the failure type of the page request with the failed request may be determined according to the status information of the page request with the failed request, and it is determined whether the determined failure type exists in the preconfigured failure types, so as to determine, according to the determination result, whether to invoke the general request retry logic or prompt a technician to manually configure the request retry logic of the page request with the failed request, so as to ensure reliability of retry of the page request with the failed request.
Optionally, on the basis of the foregoing embodiments, the present embodiment may also pre-configure retry times of the failed request, so as to avoid endless repetition and reduce performance of the Jquery, specifically, referring to fig. 5, on the basis of the method steps described in the foregoing embodiments, the page request failure processing method provided by the present invention may further include, but is not limited to, the following steps:
step S31, determining that the retransmitted page request fails, and acquiring the current retry times of the page request;
for each page request with failed request, when the page request still fails after being retransmitted, the present embodiment may monitor the number of retransmissions,
step S32, judging whether the current retry number reaches the preset number, if so, entering step S33; if not, executing step S34;
it should be noted that the specific value of the preset number is not limited in this embodiment, and is usually not very large. Optionally, different preset times may be set for different page requests, that is, the maximum number of times of retries allowed for different page requests may be different, and of course, may also be the same, which is not limited in this embodiment.
Step S33, deleting the page request;
for a page request with the retry number reaching the preset number, the page request cannot be retransmitted, and the page request may be discarded, and at this time, corresponding prompt information may be fed back for the page request according to needs, such as request failure, and the like.
Step S34, continuing to trigger the request retry logic until the retry times of the page request reach the preset times or the request data of the page request are received
As for the specific implementation of step S34, reference may be made to the description of step S13 and step S14 described in the above embodiments.
In summary, for example, in addition to pre-configuring the general request retry logic, the maximum retry number of each page request, that is, the preset number, may be pre-configured, so that in practical applications, it is determined that the retry number of the page request with a failed request reaches the preset number, and the page request with a failed request will give up retries, thereby avoiding that a large number of retries of invalid page requests affect the performance of the device.
It should be understood that, for the above embodiments, the steps of at least two alternative embodiments may be combined according to different requirements to obtain an embodiment in a new application scenario, which all belong to the protection scope of the present invention, and are not described in detail herein.
Referring to fig. 6, a schematic structural diagram of a page request failure processing apparatus provided in an embodiment of the present invention, where the apparatus may be applied to a computer device, and may specifically include, but is not limited to the following functional modules:
the state monitoring module 61 is used for monitoring the state information of the page request with failed request;
a status determining module 62, configured to determine whether the status information matches a preconfigured failure type;
optionally, as shown in fig. 7, the state determining module 62 may specifically include:
a current failure type determining unit 621, configured to determine a failure type of the page request that fails to request according to the state information;
a determining unit 622, configured to determine whether a failure type of the page request exists in preconfigured failure types; a reminding unit 623, configured to output configuration prompt information if the determination result of the failure type determining unit is negative;
the configuration prompt message is used for reminding a user of configuring request retry logic for the page request with failed request.
As another alternative, the status determination module 62 may also include:
and the state detection unit is used for inquiring whether the state information of the page request exists or not from the state information matched with the preconfigured failure type.
A request retry logic calling module 63, configured to, if the determination result of the state determination module is yes, call a request retry logic corresponding to a preconfigured failure type that matches the state information according to a correspondence between the preconfigured failure type and the request retry logic;
in practical application of this embodiment, after a request fails, a corresponding request retry logic may be directly called for retry, or after a user trigger is received, a request retry logic may be called again for retry, where this embodiment does not limit a trigger manner of the failed request retry.
Based on this, as shown in fig. 8, the request retry logic invoking module 63 may include:
a failure type judging unit 631 configured to judge whether a preconfigured failure type matching the status information is a first failure type; wherein the first failure type may be a failure type preset to manually trigger a request retry logic.
A first invoking unit 632, configured to receive a retry instruction generated based on a user trigger operation and invoke a request retry logic corresponding to a preconfigured failure type matching the state information in response to the retry instruction, if a determination result of the failure type determining unit is yes;
a second calling unit 633, configured to generate a retry instruction if the determination result of the failure type determining unit is negative, and call, in response to the retry instruction, a request retry logic corresponding to a preconfigured failure type that matches the state information.
For specific implementation of the above two ways of triggering retry, namely, automatic triggering and manual triggering, reference may be made to the description of the corresponding parts of the above method embodiments.
A request retry logic execution module 64 for executing the invoked request retry logic to resend the request for the page that failed the request.
In this embodiment, before executing the request retry logic, the request retry logic may be inserted into a failure handling function of the page request, so that the apparatus may further include:
the configuration modification module is used for inserting the called request retry logic into a failure processing function of the page request with failed request;
accordingly, the request retry logic execution module 64 is specifically configured to execute the failure handling function to resend the page request with failed request.
In summary, in this embodiment, a large number of page requests with request failures are divided into multiple failure types in advance, and a request retry logic is not configured for each failure type, so that the multiple page requests with request failures corresponding to the failure types can call the request retry logic to resend the page request with request failures, specifically, whether the state information of the page request with request failures matches the failure types configured in advance is determined, to detect whether the page request with current request failures can call a universal request retry logic configured in advance, and if the result of the determination is yes, the universal request retry logic configured in advance is called to resend the page request with request failures, and a request retry logic required for manual configuration of the page request retry logic is not required, so that the configuration workload of the request retry logic is reduced, the processing efficiency of the page request with failures is improved, and further the page local refresh efficiency and reliability are improved.
Based on the above analysis, as shown in fig. 9, the page request failure processing apparatus provided in this embodiment may further include:
a page request obtaining module 65, configured to obtain all page requests initiated for a target page;
a failure type determining module 66, configured to determine a failure type corresponding to each page request failure, and use the failure type of the page request corresponding to the multiple request failures as a preconfigured failure type;
a request retry logic obtaining module 67, configured to obtain the configured request retry logic for each preconfigured failure type, and establish a corresponding relationship between the request retry logic and the preconfigured failure type.
Optionally, as shown in fig. 10, on the basis of the foregoing embodiment, the present embodiment may further pre-configure the retry number of the failed request, and therefore, the page request failure processing apparatus provided by the present invention may further include:
a current retry number obtaining module 68, configured to determine that the retransmitted page request fails to be requested, and obtain a current retry number of the page request;
a retry number judging module 69, configured to judge whether the current retry number reaches a preset number, and if not, continue to trigger the request retry logic executing module to execute the request retry logic until the retry number of the page request reaches the preset number, or receive the request data of the page request;
the page request deleting module 610 is configured to delete the page request if the determination result of the retry number determining module 69 is yes.
As can be seen, the maximum retry number of the failed page request may also be preconfigured in this embodiment, so that, for the page request that fails to be requested, the request still fails after being retransmitted, and the embodiment may continue to retry until the request succeeds or the retry number reaches the preset maximum retry number, thereby avoiding constantly retrying the failed page request, and reducing the performance of the computer device.
In this embodiment, the page request failure processing apparatus described in each of the above embodiments may include a processor and a memory, and the state monitoring module, the state determining module, the request retry logic calling module, the request retry logic executing module, the current failure type determining unit, the prompting unit, the failure type determining unit, the first calling unit, the second calling unit, the page request acquiring module, the failure type determining module, the request retry logic acquiring module, the current retry number acquiring module, the retry number determining module, the page request deleting module, and the like are all stored in the memory as program units, and the processor executes the program units stored in the memory to implement corresponding functions.
The processor may include a kernel, and the kernel calls the corresponding program unit from the memory. The kernel can set one or more than one kernel, monitors the state information of the page request with the failed request by adjusting kernel parameters, detects whether the page request with the failed request needs manual configuration request retry logic by judging whether the state information is matched with the failure type configured in advance, if the judgment result is negative, the manual configuration is not needed, and can call the request retry logic corresponding to the failure type configured in advance, so that the page request with the failed request can be retried, the configuration workload of the request retry logic is reduced, the processing efficiency of the failed page request is improved, and the local page refreshing efficiency and reliability are improved.
The memory may include volatile memory in a computer readable medium, random Access Memory (RAM) and/or nonvolatile memory such as Read Only Memory (ROM) or flash memory (flash RAM), and the memory includes at least one memory chip.
An embodiment of the present invention provides a storage medium, on which a program is stored, where the program, when executed by a processor, implements the page request failure processing method described in the above method embodiment.
The embodiment of the invention provides a processor, which is used for running a program, wherein the page request failure processing method is executed when the program runs.
As shown in the hardware structure diagram of fig. 11, an embodiment of the present invention provides a computer device, where the computer device may include: a communication interface 111, a memory 112, and a processor 113, wherein:
the number of the communication interface 111, the memory 112, and the processor 113 may be at least one, and the communication interface 111, the memory 112, and the processor 113 may communicate with each other through a communication bus.
The communication interface 111 may be configured to receive messages sent by an external device, such as various page requests, and may also be configured to feed back a request response result to the external device, which may be determined according to requirements of an actual application scenario, and this embodiment is not described in detail herein.
Optionally, the communication interface may include a wired or wireless network interface, such as a WIFI network interface, a GPRS network interface, and the like, and the type of the interface included in the communication interface is not limited in this embodiment.
A memory 112 for storing a program for implementing the page request failure processing method described above;
a processor 113 for loading and executing the memory-stored program for:
monitoring state information of a page request with a failed request;
judging whether the state information is matched with a preset failure type;
if so, calling a request retry logic corresponding to the preconfigured failure type matched with the state information according to the corresponding relation between the preconfigured failure type and the request retry logic;
executing the invoked request retry logic to resend the request-failed page request.
Optionally, the following steps may be implemented when the processor executes the program:
determining the failure type of the page request with failed request according to the state information;
and judging whether the failure type of the page request exists in the pre-configured failure types.
Optionally, the following steps may be implemented when the processor executes the program:
and inquiring whether the state information of the page request exists in the state information matched with the preconfigured failure type.
Optionally, the following steps may be implemented when the processor executes the program:
under the condition that the judgment result is negative, outputting configuration prompt information;
and the configuration prompt message is used for reminding a user of the page request configuration request retry logic which fails to request.
Optionally, the following steps may also be implemented when the processor executes the program:
judging whether a preconfigured failure type matched with the state information is a first failure type, wherein the first failure type is a failure type of a preset manual trigger request retry logic;
if yes, receiving a retry instruction generated based on user trigger operation, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
if not, generating a retry instruction, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information.
Optionally, referring to the flowchart shown in fig. 12, when the processor executes the program, the following steps may also be implemented:
determining that the retransmitted page request fails to be sent again, and acquiring the current retry times of the page request;
judging whether the current retry times reach preset times or not;
if so, deleting the page request;
and if not, continuing to trigger the execution of the request retry logic until the retry times of the page request reach the preset times or receiving the request data of the page request.
Optionally, the following steps may also be implemented when the processor executes the program:
acquiring all page requests initiated aiming at a target page;
determining a failure type corresponding to the failure of each page request, and taking the failure types corresponding to the multiple page requests as failure types configured in advance;
acquiring a request retry logic configured for each preconfigured failure type, and establishing a corresponding relation between the request retry logic and the preconfigured failure types.
Optionally, the following steps may also be implemented when the processor executes the program:
inserting the called request retry logic into a failure processing function of the page request with failed request;
the request retry logic of the execution call comprising:
the failure handling function is executed.
In practical applications, the computer device provided by the present embodiment may be a database, such as the Jquery database described above.
Embodiments of the present invention further provide a computer program product, which, when executed on a computer device, is adapted to execute a program that initializes the following method steps:
monitoring the state information of the page request with failed request;
judging whether the state information is matched with a preset failure type;
if so, calling a request retry logic corresponding to the preconfigured failure type matched with the state information according to the corresponding relation between the preconfigured failure type and the request retry logic;
executing the invoked request retry logic to resend the request-failed page request.
Optionally, the computer product may further implement the following steps when executing the program:
determining the failure type of the page request with failed request according to the state information;
and judging whether the failure type of the page request exists in the pre-configured failure types.
Optionally, the computer product may further implement the following steps when executing the program:
and inquiring whether the state information of the page request exists in the state information matched with the preconfigured failure type.
Optionally, the following steps may also be implemented when the processor executes the program:
under the condition that the judgment result is negative, outputting configuration prompt information;
and the configuration prompt message is used for reminding a user of the page request configuration request retry logic which fails to request.
Optionally, the computer product may further implement the following steps when executing the program:
judging whether a preconfigured failure type matched with the state information is a first failure type, wherein the first failure type is a failure type of a preset manual trigger request retry logic;
if yes, receiving a retry instruction generated based on user trigger operation, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
and if not, generating a retry instruction, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information.
Optionally, the computer product may further implement the following steps when executing the program:
determining that the retransmitted page request fails to be sent again, and acquiring the current retry times of the page request;
judging whether the current retry times reach preset times or not;
if so, deleting the page request;
and if the page request does not reach the preset number, continuing to trigger the execution of the request retry logic until the retry number of the page request reaches the preset number or the request data of the page request is received.
Optionally, the following steps can be implemented when the computer product executes the program:
acquiring all page requests initiated aiming at a target page;
determining a failure type corresponding to the failure of each page request, and taking the failure types corresponding to the multiple page requests as failure types configured in advance;
acquiring a request retry logic configured for each preconfigured failure type, and establishing a corresponding relation between the request retry logic and the preconfigured failure types.
Optionally, the following steps can be implemented when the computer product executes the program:
inserting the called request retry logic into a failure processing function of the page request with failed request;
the request retry logic of the execution call includes:
the failure handling function is executed.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, apparatus, computer device or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus, computer devices and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable message processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, apparatus, computer device or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
The above are merely examples of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present application shall be included in the scope of the claims of the present application.
Claims (7)
1. A page request failure processing method is characterized by comprising the following steps:
monitoring the state information of the page request with failed request;
judging whether the state information is matched with a preset failure type;
if so, calling a request retry logic corresponding to the preconfigured failure type matched with the state information according to the corresponding relation between the preconfigured failure type and the request retry logic; caching the page requests corresponding to the request failures of the same failure type into a globalErrors array, and enabling each page request cached into the globalErrors array to directly call the same request retry logic;
executing the invoked request retry logic to resend the page request for which the request failed;
the invoking of the request retry logic corresponding to the preconfigured failure type matched with the state information includes:
judging whether a preconfigured failure type matched with the state information is a first failure type, wherein the first failure type is a failure type of a preset manual trigger request retry logic;
if yes, receiving a retry instruction generated based on user trigger operation, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
if not, generating a retry instruction, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
wherein the determining whether the state information matches a preconfigured failure type includes:
inquiring whether the state information of the page request exists or not from the state information matched with the preconfigured failure type;
wherein the method further comprises:
under the condition that the judgment result is negative, outputting configuration prompt information;
and the configuration prompt message is used for reminding a user of the page request configuration request retry logic which fails to request.
2. The method of claim 1, wherein determining whether the status information matches a preconfigured failure type comprises:
determining the failure type of the page request with failed request according to the state information;
and judging whether the failure type of the page request exists in the pre-configured failure types.
3. The method according to claim 1 or 2, wherein after resending the page request for which the request failed, the method further comprises:
determining that the retransmitted page request fails to be sent again, and acquiring the current retry times of the page request;
judging whether the current retry times reach preset times or not;
if so, deleting the page request;
and if not, continuing to trigger the execution of the request retry logic until the retry times of the page request reach the preset times or receiving the request data of the page request.
4. The method according to claim 1 or 2, characterized in that the method further comprises:
acquiring all page requests initiated aiming at a target page;
determining a failure type corresponding to failure of each page request, and taking the failure types of the page requests corresponding to a plurality of request failures as failure types configured in advance;
acquiring a request retry logic configured for each preconfigured failure type, and establishing a corresponding relation between the request retry logic and the preconfigured failure types.
5. The method according to claim 1 or 2, characterized in that the method further comprises:
inserting the called request retry logic into a failure handling function of the page request with a failed request;
the request retry logic of the execution call comprising:
the failure handling function is executed.
6. An apparatus for processing page request failure, the apparatus comprising:
the state monitoring module is used for monitoring the state information of the page request with failed request;
the state judgment module is used for judging whether the state information is matched with a preset failure type;
a request retry logic calling module, configured to, if the determination result of the state determination module is yes, call a request retry logic corresponding to a preconfigured failure type that matches the state information according to a correspondence between the preconfigured failure type and the request retry logic; caching the page requests corresponding to the request failures of the same failure type into a globalErrors array, and enabling each page request cached into the globalErrors array to directly call the same request retry logic;
a request retry logic execution module for executing the invoked request retry logic to resend the page request for which the request failed;
the calling of the request retry logic corresponding to the preconfigured failure type matched with the state information in the request retry logic calling module includes:
judging whether a preconfigured failure type matched with the state information is a first failure type, wherein the first failure type is a failure type of a preset manual trigger request retry logic;
if yes, receiving a retry instruction generated based on user trigger operation, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
if not, generating a retry instruction, responding to the retry instruction, and calling a request retry logic corresponding to a preconfigured failure type matched with the state information;
wherein the determining whether the state information matches a preconfigured failure type includes:
inquiring whether the state information of the page request exists in the state information matched with the preconfigured failure type;
wherein the apparatus further comprises:
under the condition that the judgment result is negative, outputting configuration prompt information;
and the configuration prompt message is used for reminding a user of the page request configuration request retry logic which fails to request.
7. A computer device, characterized in that the computer device comprises:
a communication interface;
a memory for storing a program for implementing the page request failure processing method according to any one of claims 1 to 5;
a processor for loading and executing the memory-stored program, the program for:
monitoring the state information of the page request with failed request;
judging whether the state information is matched with a preset failure type;
if so, calling a request retry logic corresponding to the preconfigured failure type matched with the state information according to the corresponding relation between the preconfigured failure type and the request retry logic;
executing the invoked request retry logic to resend the page request for which the request failed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811099007.8A CN110929202B (en) | 2018-09-20 | 2018-09-20 | Page request failure processing method and device and computer equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811099007.8A CN110929202B (en) | 2018-09-20 | 2018-09-20 | Page request failure processing method and device and computer equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110929202A CN110929202A (en) | 2020-03-27 |
| CN110929202B true CN110929202B (en) | 2023-01-17 |
Family
ID=69856239
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811099007.8A Active CN110929202B (en) | 2018-09-20 | 2018-09-20 | Page request failure processing method and device and computer equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110929202B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111708963B (en) * | 2020-05-22 | 2023-09-29 | 北京百度网讯科技有限公司 | Page request processing method and device, electronic equipment and storage medium |
| CN111629056B (en) * | 2020-05-27 | 2023-04-07 | 浙江百世技术有限公司 | Network request processing method and application |
| CN112087510B (en) * | 2020-09-08 | 2022-10-28 | 中国工商银行股份有限公司 | Request processing method, device, electronic equipment and medium |
| CN112100218A (en) * | 2020-09-18 | 2020-12-18 | 深圳乐信软件技术有限公司 | Quasi-real-time request processing method and device, computer equipment and storage medium |
| CN112486719B (en) * | 2020-12-14 | 2023-07-04 | 上海万物新生环保科技集团有限公司 | Method and equipment for RPC interface call failure processing |
| CN113438294A (en) * | 2021-06-22 | 2021-09-24 | 康键信息技术（深圳）有限公司 | Service request processing method, device, equipment and storage medium |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2124174A1 (en) * | 2008-05-19 | 2009-11-25 | Accenture Global Services GmbH | Service exception resolution framework |
| US20100323725A1 (en) * | 2009-06-18 | 2010-12-23 | Yigang Cai | Individualized retry configurations for messages having failed delivery |
| CN103973419A (en) * | 2013-01-31 | 2014-08-06 | 中兴通讯股份有限公司 | Short message service center and short message service retransmitting method |
| CN105095022B (en) * | 2015-07-31 | 2018-06-08 | 北京金山安全软件有限公司 | Data backup method and device |
| US10007891B2 (en) * | 2015-09-18 | 2018-06-26 | Sap Se | Re-processing requests in automated warehouses |
| CN106502769B (en) * | 2016-09-30 | 2019-11-05 | 华为技术有限公司 | Distributed transaction processing method, apparatus and system |
-
2018
- 2018-09-20 CN CN201811099007.8A patent/CN110929202B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN110929202A (en) | 2020-03-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110929202B (en) | Page request failure processing method and device and computer equipment | |
| CN110096659B (en) | Page display method, device and equipment and readable storage medium | |
| US10812566B2 (en) | Distributed steam processing | |
| US9954855B2 (en) | Login method and apparatus, and open platform system | |
| AU2017215589B2 (en) | Electronic payment service processing method and device, and electronic payment method and device | |
| CN110825420B (en) | Method, device, equipment and storage medium for updating configuration parameters of distributed cluster | |
| CN112637346A (en) | Proxy method, device, proxy server and storage medium | |
| CN106533944B (en) | Distributed API gateway, management method and management system | |
| US11184465B2 (en) | Network communication for establishing a QUIC connection | |
| CN107528858B (en) | Login method, device and equipment based on webpage and storage medium | |
| CN105337787A (en) | Multi-server monitoring method, device and system | |
| CN111262839A (en) | Vulnerability scanning method, management equipment, node and storage medium | |
| US9137094B1 (en) | Method for setting DNS records | |
| WO2019127890A1 (en) | Vulnerability scanning method, device, computer apparatus, and storage medium | |
| US11196728B1 (en) | Caching login sessions to access a software testing environment | |
| KR102242219B1 (en) | Method and device for preventing the server from being attacked | |
| CN107181636B (en) | Health check method and device in load balancing system | |
| US20150373011A1 (en) | Credential collection in an authentication server employing diverse authentication schemes | |
| CN110750443A (en) | Webpage testing method and device, computer equipment and storage medium | |
| CN112733001A (en) | Method and device for acquiring subscription information and electronic equipment | |
| CN107547468B (en) | Network protocol switching device, method and terminal | |
| CN112714166A (en) | Multi-cluster management method and device for distributed storage system | |
| CN107239475B (en) | File calling method and device | |
| CN112583879A (en) | Request processing method, device and system, storage medium and electronic equipment | |
| CN113064732A (en) | Distributed system and management method thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |