After you create a service retry rule for a multi-language application, if the application is temporarily inaccessible or encounters an occasional error, a request is retired to ensure that the expected results can be returned. This improves the robustness of the system. This topic describes how to create a service retry rule for a multi-language application.

Precautions

If you create both a service timeout rule and a service retry rule for an application, the timeout period that you specify for the former rule may affect the number of retries allowed.

For example, you set the timeout period to 1,000 ms and the maximum number of retries to five for errors with a code of 5xx for an application. If the application takes 300 ms to process a request, a timeout error occurs after the application attempts to process the third retry although a maximum of five retries are allowed. The following figure shows the detailed information:

Create a service retry rule

  1. Log on to the EDAS console.
  2. In the left-side navigation pane, choose Microservices Governance > Service Mesh.
  3. In the left-side navigation tree of the Service Mesh page, click Service Retry Setting.
  4. Select a region in the top navigation bar. Select a microservice namespace from the drop-down list next to Retry and click Create rule.
  5. In the Create a service retry rule panel, set the parameters and click OK.
    Create a service retry rule in EDAS

    The following table describes the parameters.

    Parameter Description
    Microservice Space The region and microservice namespace where the application resides.
    Rule name The name of the service retry rule, such as retry-example.
    Application The application for which you want to create the service retry rule.
    Tag The tag that implements tag-based routing.
    Status Specifies whether to enable the service retry rule.
    • On: enables the rule after it is created.
    • Off: disables the rule after it is created. To enable the rule, find the rule on the Retry page and click Open in the Operation column.
    Protocol type The type of the application framework. Default value: Service Mesh.
    Traffic sources The one or more consumer applications that send requests. You can select All or specify specific applications.
    Note A request can be resent only if the consumer application that sends the request is specified for this parameter.
    Maximum retry times The maximum number of retries allowed.
    Timeout response time for each retry The timeout period of retries. If the application fails to process the retry within the specified period, a timeout error is returned. Unit: milliseconds.
    Note If more retries are allowed, the request can be resent.
    Trigger condition The condition to trigger retries. Valid values:
    • 5xx: resends the request if an HTTP status code from 500 to 599 is returned. The value 5xx represents the following four trigger conditions:
      • gateway-error: resends the request if the 502, 503, or 504 HTTP status code is returned.
      • reset: resends the request if no results are returned.
      • connect-failure: resends the request if the network connection fails. For example, retires are triggered if the connection times out.
      • reused-stream: resends the request if the stream is refused.
    • retriable-4xx: resends the request if the 409 HTTP status code is returned.
    After the service retry rule is created and enabled, check whether the rule takes effect.

Related operations

After you create a service retry rule, you can click Edit, Close, or Open in the Operation column to manage the rule. If the service retry rule is no longer required, you can click Delete to delete the rule.