|
| 1 | +--- |
| 2 | +title: Implement a retry policy for Azure Storage services |
| 3 | +description: Learn about retry policies and how to implement them for Azure Storage services. This article helps you set up a retry policy for blob storage requests using the .NET v12 SDK. |
| 4 | +author: pauljewellmsft |
| 5 | +ms.author: pauljewell |
| 6 | +ms.service: storage |
| 7 | +ms.topic: how-to |
| 8 | +ms.date: 08/23/2022 |
| 9 | +ms.custom: template-how-to |
| 10 | +--- |
| 11 | + |
| 12 | +<!-- |
| 13 | +Remove all the comments in this template before you sign-off or merge to the |
| 14 | +main branch. |
| 15 | +--> |
| 16 | + |
| 17 | +<!-- |
| 18 | +This template provides the basic structure of a how-to article. |
| 19 | +See the [how-to guidance](contribute-how-to-write-howto.md) in the contributor guide. |
| 20 | +
|
| 21 | +To provide feedback on this template contact |
| 22 | +[the templates workgroup](mailto:[email protected]). |
| 23 | +--> |
| 24 | + |
| 25 | +<!-- 1. H1 |
| 26 | +Required. Start your H1 with a verb. Pick an H1 that clearly conveys the task the |
| 27 | +user will complete. |
| 28 | +--> |
| 29 | + |
| 30 | +# Implement a retry policy for Azure Storage services |
| 31 | + |
| 32 | +Any application that runs in the cloud or communicates with remote services and resources must be able to handle transient faults. It's common for cloud applications and services to experience faults due to a momentary loss of network connectivity, a request timeout when a service or resource is busy, or a number of other factors. Developers should build applications to handle transient faults transparently to improve stability and resiliency. |
| 33 | + |
| 34 | +This article shows you how to set up a basic retry strategy for an application that connects to Azure blob storage. This strategy is one element to consider as part of a broader retry policy for your application. |
| 35 | + |
| 36 | +<!-- 3. Prerequisites |
| 37 | +Optional. If you need prerequisites, make them your first H2 in a how-to guide. |
| 38 | +Use clear and unambiguous language and use a list format. |
| 39 | +--> |
| 40 | + |
| 41 | +## Prerequisites |
| 42 | + |
| 43 | +- <!-- prerequisite 1 --> |
| 44 | +- <!-- prerequisite 2 --> |
| 45 | +- <!-- prerequisite n --> |
| 46 | +<!-- remove this section if prerequisites are not needed --> |
| 47 | + |
| 48 | +<!-- 4. H2s |
| 49 | +Required. A how-to article explains how to do a task. The bulk of each H2 should be |
| 50 | +a procedure. |
| 51 | +--> |
| 52 | + |
| 53 | +## [Section 1 heading] |
| 54 | +Retry policies are configured programmatically. |
| 55 | +1. <!-- Step 1 --> |
| 56 | +1. <!-- Step 2 --> |
| 57 | +1. <!-- Step n --> |
| 58 | + |
| 59 | +## [Section 2 heading] |
| 60 | +<!-- Introduction paragraph --> |
| 61 | +1. <!-- Step 1 --> |
| 62 | +1. <!-- Step 2 --> |
| 63 | +1. <!-- Step n --> |
| 64 | + |
| 65 | +## [Section n heading] |
| 66 | +<!-- Introduction paragraph --> |
| 67 | +1. <!-- Step 1 --> |
| 68 | +1. <!-- Step 2 --> |
| 69 | +1. <!-- Step n --> |
| 70 | + |
| 71 | +<!-- 5. Next steps |
| 72 | +Required. Provide at least one next step and no more than three. Include some |
| 73 | +context so the customer can determine why they would click the link. |
| 74 | +--> |
| 75 | + |
| 76 | +## Next steps |
| 77 | +<!-- Add a context sentence for the following links --> |
| 78 | +- For architectural guidance and general best practices around retry policies, please see [Transient fault handling](/azure/architecture/best-practices/transient-faults). |
| 79 | +- [Links](links-how-to.md) |
| 80 | + |
| 81 | +<!-- |
| 82 | +Remove all the comments in this template before you sign-off or merge to the |
| 83 | +main branch. |
| 84 | +--> |
0 commit comments