Merge pull request #269587 from spelluru/sbusfreshness0319

Service Bus - freshness

Author: American-Dipper

articles/service-bus-messaging/service-bus-resource-manager-exceptions.md

@@ -1,18 +1,15 @@
 ---
-title: Azure Service Bus Resource Manager exceptions | Microsoft Docs
-description: List of Service Bus exceptions surfaced by Azure Resource Manager and suggested actions.
+title: Azure Service Bus Resource Manager exceptions
+description: This article provides a list of Service Bus exceptions surfaced by Azure Resource Manager and suggested actions.
 ms.topic: article
 ms.custom: devx-track-arm-template
-ms.date: 10/25/2022
+ms.date: 03/19/2024
 ---
 
 # Service Bus Resource Manager exceptions
 
 This article lists exceptions generated when interacting with Azure Service Bus using Azure Resource Manager - via templates or direct calls.
 
-> [!IMPORTANT]
-> This document is frequently updated. Please check back for updates.
-
 Here are the various exceptions/errors that are surfaced through the Azure Resource Manager.
 
 ## Error: Bad Request
@@ -23,7 +20,7 @@ Here are the various exceptions/errors that are surfaced through the Azure Resou
 | ---------- | ------------- | ------------- | ----------- | -------------- |
 | Bad Request | 40000 | Sub code=40000. The property *'property name'* can't be set when creating a Queue because the namespace *'namespace name'* is using the 'Basic' Tier. This operation is only supported in 'Standard' or 'Premium' tier. | On Azure Service Bus Basic Tier, the below properties can't be set or updated - <ul> <li> RequiresDuplicateDetection </li> <li> AutoDeleteOnIdle </li> <li>RequiresSession</li> <li>DefaultMessageTimeToLive </li> <li> DuplicateDetectionHistoryTimeWindow </li> <li> EnableExpress (not supported in Premium too)</li> <li> ForwardTo </li> <li> Topics </li> </ul> | Consider upgrading from Basic to Standard or Premium tier to use this functionality. |
 | Bad Request | 40000 | Sub code=40000. The value for the 'requiresDuplicateDetection' property of an existing Queue(or Topic) can't be changed. | Duplicate detection must be enabled/disabled at the time of entity creation. The duplicate detection configuration parameter can't be changed after creation. | To enable duplicate detection on a previously created queue/topic, you can create a new queue/topic with duplicate detection and then forward from the original queue to the new queue/topic. |
-| Bad Request | 40000 | Sub code=40000. The specified value 16384 is invalid. The property 'MaxSizeInMegabytes', must be one of the following values: 1024;2048;3072;4096;5120. | The MaxSizeInMegabytes value is invalid. | Ensure that the MaxSizeInMegabytes is one of the following - 1024, 2048, 3072, 4096, 5120. |
+| Bad Request | 40000 | Sub code=40000. The specified value 16384 is invalid. The property `MaxSizeInMegabytes` must be one of the following values: 1024;2048;3072;4096;5120. | The MaxSizeInMegabytes value is invalid. | Ensure that the MaxSizeInMegabytes is one of the following - 1024, 2048, 3072, 4096, 5120. |
 | Bad Request | 40000 | Sub code=40000. Partitioning can't be changed for Queue/Topic. | Partitioning can't be changed for entity. | Create a new entity (queue or topic) and enable partitions. | 
 | Bad Request | none | The namespace *'namespace name'* doesn't exist. | The namespace doesn't exist within your Azure subscription. | To resolve this error: <ul> <li> Ensure that the Azure Subscription is correct. </li> <li> Ensure the namespace exists. </li> <li> Verify the namespace name is correct (no spelling errors or null strings). </li> </ul> | 
 | Bad Request | 40000 | Sub code=40000. The supplied lock time exceeds the allowed maximum of '5' minutes. | The time for which a message can be locked must be between 1 minute (minimum) and 5 minutes (maximum). | Ensure that the supplied lock time is between 1 min and 5 mins. |
@@ -36,16 +33,16 @@ Here are the various exceptions/errors that are surfaced through the Azure Resou
 
 ## Error code: 429
 
-Just like in HTTP, "Error code 429" indicates "too many requests". It implies that the specific resource (namespace) is being throttled because of too many requests (or due to conflicting operations) on that resource.
+Just like in HTTP, "Error code 429" indicates too many requests. It implies that the specific resource (namespace) is being throttled because of too many requests (or due to conflicting operations) on that resource.
 
 | Error code | Error sub code | Error message | Description | Recommendation |
 | ---------- | ------------- | ------------- | ----------- | -------------- |
 | 429 | 50004 | Sub code=50004. The request was terminated because the namespace *your namespace* is being throttled. | This error condition is hit when the number of incoming requests exceed the limitation of the resource. | Wait for a few seconds and try again. <br/> <br/> Learn more about the [quotas](service-bus-quotas.md) and [Azure Resource Manager request limits](../azure-resource-manager/management/request-limits-and-throttling.md)|
 | 429 | 40901 | Sub code=40901. Another conflicting operation is in progress. | Another conflicting operation is in progress on the same resource/entity | Wait for the current in-progress operation to complete before trying again. |
-| 429 | 40900 | Sub code=40900. Conflict. You're requesting an operation that isn't allowed in the resource's current state. | This condition may be hit when multiple requests are made to perform the operations on the same entity (queue, topic, subscription, or rule) at the same time. | Wait for a few seconds and try again |
+| 429 | 40900 | Sub code=40900. Conflict. You're requesting an operation that isn't allowed in the resource's current state. | This condition might be hit when multiple requests are made to perform the operations on the same entity (queue, topic, subscription, or rule) at the same time. | Wait for a few seconds and try again |
 | 429 | 40901 | Request on entity *'entity name'* conflicted with another request | Another conflicting operation is in progress on the same resource/entity | Wait for the previous operation to complete before trying again |
-| 429 | 40901 | Another update request is in progress for the entity *'entity name'*. | Another conflicting operation is in progress on the same resource/entity | Wait for the previous operation to complete before trying again |
-| 429 | none | Resource Conflict Occurred. Another conflicting operation may be in progress. If this operation is a retry for failed operation, background cleanup is still pending. Try again later. | This condition may be hit when there's a pending operation against the same entity. | Wait for the previous operation to complete before trying again. |
+| 429 | 40901 | Another update request is in progress for the entity: `<entity name>`. | Another conflicting operation is in progress on the same resource/entity | Wait for the previous operation to complete before trying again |
+| 429 | none | Resource Conflict Occurred. Another conflicting operation might be in progress. If this operation is a retry for failed operation, background cleanup is still pending. Try again later. | This condition might be hit when there's a pending operation against the same entity. | Wait for the previous operation to complete before trying again. |
 
 
 ## Error code: Not Found
@@ -61,7 +58,7 @@ This class of errors indicates that the resource wasn't found.
 
 ## Error code: Internal Server Error
 
-This class of errors indicates that there was an internal server error
+This class of errors indicates that there was an internal server error.
 
 | Error code | Error sub code | Error message | Description | Recommendation |
 | ---------- | ------------- | ------------- | ----------- | -------------- |

articles/service-bus-messaging/service-bus-throttling.md

@@ -1,21 +1,22 @@
 ---
-title: Overview of Azure Service Bus throttling | Microsoft Docs
-description: Overview of Service Bus throttling - Standard and Premium tiers.
-ms.topic: article
-ms.date: 11/14/2022
+title: Azure Service Bus throttling
+description: This article describes throttling in Azure Service Bus standard and premium tiers, and answers some frequently asked questions. 
+ms.topic: concept-article
+ms.date: 03/19/2024
+#customer intent: As a developer, I want to know how Azure Service Bus throttles when there are huge number of operations requested. 
 ---
 
 # Throttling operations on Azure Service Bus
 
-Cloud native solutions give a notion of unlimited resources that can scale with your workload. While this notion is more true in the cloud than it is with on-premises systems, there are still limitations that exist in the cloud. These limitations may cause [throttling](/azure/architecture/patterns/throttling) of client application requests in both standard and premium tiers as discussed in this article. 
+Cloud native solutions give a notion of unlimited resources that can scale with your workload. While this notion is more true in the cloud than it is with on-premises systems, there are still limitations that exist in the cloud. These limitations might cause [throttling](/azure/architecture/patterns/throttling) of client application requests in both standard and premium tiers as discussed in this article. 
 
 ## Throttling in standard tier
 
-The standard tier of Service Bus operates as a multi-tenant setup with a pay-as-you-go pricing model. Here multiple namespaces in the same cluster share the allocated resources. Standard tier is the recommended choice for developer environments, QA environments, and low throughput production systems.
+The standard tier of Service Bus operates as a multitenant setup with a pay-as-you-go pricing model. Here multiple namespaces in the same cluster share the allocated resources. Standard tier is the recommended choice for developer environments, QA environments, and low throughput production systems.
 
 In the past, Service Bus had coarse throttling limits strictly dependent on resource utilization. However, there's an opportunity to refine throttling logic and provide predictable throttling behavior to all namespaces that are sharing these resources.
 
-In an attempt to ensure fair usage and distribution of resources across all the Service Bus standard namespaces that use the same resources, the throttling logic has been modified to be credit-based.
+In an attempt to ensure fair usage and distribution of resources across all the Service Bus standard namespaces that use the same resources, Service Bus standard currently uses the credit-based throttling logic.
 
 > [!NOTE]
 > It is important to note that throttling is **not new** to Azure Service Bus, or any cloud native service.
@@ -26,14 +27,14 @@ In an attempt to ensure fair usage and distribution of resources across all the
 
 Credit-based throttling limits the number of operations that can be performed on a given namespace in a specific time period. Here's the workflow for credit-based throttling. 
 
-  * At the start of each time period, Service Bus provides a certain number of credits to each namespace.
-  * Any operations performed by the sender or receiver client applications will be counted against these credits (and subtracted from the available credits).
+  * At the start of each time period, Service Bus provides some credits to each namespace.
+  * Any operations performed by the sender or receiver client applications are counted against these credits (and subtracted from the available credits).
   * If the credits are depleted, subsequent operations will be throttled until the start of the next time period.
   * Credits are replenished at the start of the next time period.
 
 ### What are the credit limits?
 
-The credit limits are currently set to **1000 credits every second** (per namespace). Not all operations are created equal. Here are the credit costs of each of the operations  
+The credit limits are currently set to **1000 credits every second** (per namespace). Not all operations are created equal. Here are the credit costs of each of the operations.  
 
 | Operation | Credit cost|
 |-----------|-----------|
@@ -43,35 +44,35 @@ The credit limits are currently set to **1000 credits every second** (per namesp
 > [!NOTE]
 > When sending to a topic, each message is evaluated against filters before being made available on the subscription. Each filter evaluation also counts against the credit limit (that is, 1 credit per filter evaluation).
 
-### How will I know that I'm being throttled?
+### How do I know that I'm being throttled?
 
 When the client application requests are being throttled, the client application receives the following server response.
 
-```
+```bash
 The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
 ```
 
 ### How can I avoid being throttled?
 
-With shared resources, it's important to enforce some sort of fair usage across various Service Bus namespaces that share those resources. Throttling ensures that any spike in a single workload doesn't cause other workloads on the same resources to be throttled. As mentioned later in the article, there's no risk in being throttled because the client SDKs (and other Azure PaaS offerings) have the default [retry policy](/azure/architecture/best-practices/retry-service-specific#service-bus) built into them. Any throttled requests will be retried with exponential backoff and will eventually go through when the credits are replenished. 
+With shared resources, it's important to enforce some sort of fair usage across various Service Bus namespaces that share those resources. Throttling ensures that any spike in a single workload doesn't cause other workloads on the same resources to be throttled. As mentioned later in the article, there's no risk in being throttled because the client software development kits (SDKs) and other Azure PaaS offerings have the default [retry policy](/azure/architecture/best-practices/retry-service-specific#service-bus) built into them. Any throttled requests are retried with exponential backoff and eventually go through when the credits are replenished. 
 
-Understandably, some applications may be sensitive to being throttled. In that case, it's recommended to [migrate your current Service Bus standard namespace to premium](service-bus-migrate-standard-premium.md). On migration, you can allocate dedicated resources to your Service Bus namespace and appropriately scale up the resources if there's a spike in your workload and reduce the likelihood of being throttled. Additionally, when your workload reduces to normal levels, you can scale down the resources allocated to your namespace.
+Understandably, some applications can be sensitive to being throttled. In that case, we recommend that you [migrate your current Service Bus standard namespace to premium](service-bus-migrate-standard-premium.md). On migration, you can allocate dedicated resources to your Service Bus namespace and appropriately scale up the resources if there's a spike in your workload and reduce the likelihood of being throttled. Additionally, when your workload reduces to normal levels, you can scale down the resources allocated to your namespace.
 
 ## Throttling in premium tier
 
 The [Service Bus premium](service-bus-premium-messaging.md) tier allocates dedicated resources, in terms of messaging units, to each namespace setup by the customer. These dedicated resources provide predictable throughput and latency and are recommended for high throughput or sensitive production grade systems. Additionally, the premium tier also enables customers to scale up their throughput capacity when they experience spikes in the workload. For more information, see [Automatically update messaging units of an Azure Service Bus namespace](automate-update-messaging-units.md).
 
 ### How does throttling work in Service Bus Premium?
 
-With exclusive resource allocation for the premium tier, throttling is purely driven by the limitations of the resources allocated to the namespace. If the number of requests are more than the current resources can service, then the requests will be throttled. 
+With exclusive resource allocation for the premium tier, throttling is purely driven by the limitations of the resources allocated to the namespace. If the number of requests are more than the current resources can service, then the requests are throttled. 
 
-### How will I know that I'm being throttled?
+### How do I know that I'm being throttled?
 
 There are various ways to identifying throttling in the Service Bus premium tier.
 
   * **Throttled Requests** show up on the [Azure Monitor Request metrics](monitor-service-bus-reference.md#request-metrics) to identify how many requests were throttled.
-  * High **CPU Usage** indicates that current resource allocation is high and requests may get throttled if the current workload doesn't reduce.
-  * High **Memory Usage** indicates that current resource allocation is high and requests may get throttled if the current workload doesn't reduce.
+  * High **CPU Usage** indicates that current resource allocation is high and requests might get throttled if the current workload doesn't reduce.
+  * High **Memory Usage** indicates that current resource allocation is high and requests might get throttled if the current workload doesn't reduce.
 
 ### How can I avoid being throttled?
 
@@ -84,20 +85,20 @@ As the Service Bus premium namespace already has dedicated resources, you can re
 
 When a request is throttled, it implies that the service is busy because it's facing more requests than the resources allow. If the same operation is tried again after a few moments, once the service has worked through its current workload, then the request can be honored.
 
-As throttling is the expected behavior of any cloud native service, retry logic is built into the Service Bus SDK itself. The default is set to auto retry with an exponential back-off to ensure that we don't have the same request being throttled each time. The default retry logic will apply to every operation.
+As throttling is the expected behavior of any cloud native service, retry logic is built into the Service Bus SDK itself. The default is set to auto retry with an exponential back-off to ensure that we don't have the same request being throttled each time. The default retry logic applies to every operation.
 
 >[!NOTE]
 > Message-processing code that calls other third-party services may be throttled by those other services as well. For more information on how to handle these scenarios, see the [documentation on the Throttling Pattern](/azure/architecture/patterns/throttling).
 
 ### Does throttling result in data loss?
 
-Azure Service Bus is optimized for persistence, we ensure that all the data sent to Service Bus is committed to storage before the service acknowledges the success of the request.
+Azure Service Bus is optimized for persistence. We ensure that all the data sent to Service Bus is committed to storage before the service acknowledges the success of the request.
 
 Once the request is successfully acknowledged by Service Bus, it implies that Service Bus has successfully processed the request. If Service Bus returns a failure, then it implies that Service Bus hasn't been able to process the request and the client application must retry the request.
 
 However, when a request is throttled, the service is implying that it can't accept and process the request right now because of resource limitations. It **does not** imply any sort of data loss because Service Bus simply hasn't looked at the request. In this case, relying on the default [retry policy](/azure/architecture/best-practices/retry-service-specific#service-bus) of the Service Bus SDK ensures that the request is eventually processed.
 
-## Next steps
+## Related content
 
 For more information and examples of using Service Bus messaging, see the following advanced topics: