You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/container-apps/dapr-component-resiliency.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ ms.custom:
20
20
21
21
# Dapr component resiliency (preview)
22
22
23
-
Resiliency policies proactively prevent, detect, and recover from your container app failures. In this article, you learn how to apply resiliency policies for applications that use Dapr to integrate with different cloud services, like state stores, pub/sub message brokers, secret stores, and more.
23
+
Resiliency policies proactively prevent, detect, and recover from your container app failures. In this article, you learn how to apply resiliency policies for applications that use Dapr to integrate with different cloud services. Such as, state stores, pub/sub message brokers, secret stores, and more.
24
24
25
25
You can configure resiliency policies like retries, timeouts, and circuit breakers for the following outbound and inbound operation directions by using a Dapr component:
26
26
@@ -322,7 +322,7 @@ The circuit waits half-open for the `timeoutInSeconds` amount of time, during wh
322
322
323
323
If you didn't set any `intervalInSeconds` value, the circuit resets to a closed state after the amount of time you set for `timeoutInSeconds`, regardless of consecutive request success or failure. If you set `intervalInSeconds` to *0*, the circuit never automatically resets, only moving from half-open to closed state by successfully completing `consecutiveErrors` requests in a row.
324
324
325
-
If you did set an `intervalInSeconds` value, that determines the amount of time before the circuit is reset to closed state, independent of whether the requests sent in half-opened state succeeded or not.
325
+
If you did set an `intervalInSeconds` value, it determines the amount of time before the circuit is reset to closed state, independent of whether the requests sent in half-opened state succeeded or not.
326
326
327
327
## Resiliency logs
328
328
@@ -342,13 +342,13 @@ ContainerAppConsoleLogs_CL
342
342
343
343
Select **Run** to run the query and view the result with the log message indicating the policy is loading.
344
344
345
-
:::image type="content" source="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png" alt-text="Screenshot showing resiliency query results based on provided query example for checking if resiliency policy has loaded." lightbox="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png":::
345
+
:::image type="content" source="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png" alt-text="Screenshot showing resiliency query results based on the provided query example for checking if the resiliency policy is loaded." lightbox="media/dapr-component-resiliency/dapr-resiliency-query-results-loading.png":::
346
346
347
347
You can also find the actual resiliency policy by enabling debug logs on your container app and querying to see if a resiliency resource is loaded.
348
348
349
349
:::image type="content" source="media/dapr-component-resiliency/dapr-debug-logs.png" alt-text="Screenshot demonstrating how to enable debug logs on your container app via the portal." lightbox="media/dapr-component-resiliency/dapr-debug-logs.png":::
350
350
351
-
Once debug logs are enabled, use a query similar to the following:
351
+
Once debug logs are enabled, use a query similar to the following example:
0 commit comments