Merge pull request #234707 from spelluru/sbus0417

Service Bus supportability issues

Author: prmerger-automator[bot]

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

@@ -39,7 +39,7 @@ Service Bus contains a number of mitigations for these issues. The following sec
 ### Throttling
 With Service Bus, throttling enables cooperative message rate management. Each individual Service Bus node houses many entities. Each of those entities makes demands on the system in terms of CPU, memory, storage, and other facets. When any of these facets detects usage that exceeds defined thresholds, Service Bus can deny a given request. The caller receives a server busy exception and retries after 10 seconds.
 
-As a mitigation, the code must read the error and halt any retries of the message for at least 10 seconds. Since the error can happen across pieces of the customer application, it is expected that each piece independently executes the retry logic. The code can reduce the probability of being throttled by enabling partitioning on a namespace, queue or topic.
+As a mitigation, the code must read the error and halt any retries of the message for at least 10 seconds. Since the error can happen across pieces of the customer application, it is expected that each piece independently executes the [retry logic](/azure/architecture/best-practices/retry-service-specific#service-bus). The code can reduce the probability of being throttled by enabling partitioning on a namespace, queue or topic.
 
 For more information on how application code should handle throttling concerns, see the [documentation on the Throttling Pattern](/azure/architecture/patterns/throttling).
 

articles/service-bus-messaging/service-bus-geo-dr.md

@@ -166,7 +166,7 @@ Note the following considerations to keep in mind with this release:
 
 ## Availability Zones
 
-The Service Bus Premium SKU supports [availability zones](../availability-zones/az-overview.md), providing fault-isolated locations within the same Azure region. Service Bus manages three copies of the messaging store (1 primary and 2 secondary). Service Bus keeps all three copies in sync for data and management operations. If the primary copy fails, one of the secondary copies is promoted to primary with no perceived downtime. If the applications see transient disconnects from Service Bus, the retry logic in the SDK will automatically reconnect to Service Bus. 
+The Service Bus Premium SKU supports [availability zones](../availability-zones/az-overview.md), providing fault-isolated locations within the same Azure region. Service Bus manages three copies of the messaging store (1 primary and 2 secondary). Service Bus keeps all three copies in sync for data and management operations. If the primary copy fails, one of the secondary copies is promoted to primary with no perceived downtime. If the applications see transient disconnects from Service Bus, the [retry logic](/azure/architecture/best-practices/retry-service-specific#service-bus) in the SDK will automatically reconnect to Service Bus. 
 
 When you use availability zones, both metadata and data (messages) are replicated across data centers in the availability zone. 
 

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

@@ -19,7 +19,8 @@ The messaging APIs generate exceptions that can fall into the following categori
 4. Other exceptions ([System.Transactions.TransactionException](/dotnet/api/system.transactions.transactionexception), [System.TimeoutException](/dotnet/api/system.timeoutexception), [Microsoft.ServiceBus.Messaging.MessageLockLostException](/dotnet/api/microsoft.azure.servicebus.messagelocklostexception), [Microsoft.ServiceBus.Messaging.SessionLockLostException](/dotnet/api/microsoft.azure.servicebus.sessionlocklostexception)). General action: specific to the exception type; refer to the table in the following section:
 
 > [!IMPORTANT]
-> Azure Service Bus doesn't retry an operation in case of an exception when the operation is in a transaction scope.
+> - Azure Service Bus doesn't retry an operation in case of an exception when the operation is in a transaction scope.
+> - For retry guidance specific to Azure Service Bus, see [Retry guidance for Service Bus](/azure/architecture/best-practices/retry-service-specific#service-bus).
 
 
 ## Exception types

articles/service-bus-messaging/service-bus-migrate-standard-premium.md

@@ -128,11 +128,11 @@ Here is a list of features not supported by Premium and their mitigation -
 
 ### Express entities
 
-   Express entities that don't commit any message data to storage are not supported in Premium. Dedicated resources provided significant throughput improvement while ensuring that data is persisted, as is expected from any enterprise messaging system.
+Express entities that don't commit any message data to storage are not supported in the **Premium** tier. Dedicated resources provided significant throughput improvement while ensuring that data is persisted, as is expected from any enterprise messaging system.
 
-   During migration, any of your express entities in your Standard namespace will be created on the Premium namespace as a non-express entity.
+During migration, any of your express entities in your Standard namespace will be created on the Premium namespace as a non-express entity.
 
-   If you utilize Azure Resource Manager (ARM) templates, please ensure that you remove the 'enableExpress' flag from the deployment configuration so that your automated workflows execute without errors.
+If you utilize Azure Resource Manager (ARM) templates, please ensure that you remove the 'enableExpress' flag from the deployment configuration so that your automated workflows execute without errors.
 
 ### RBAC settings
 The role-based access control (RBAC) settings on the namespace aren't migrated to the premium namespace. You'll need to add them manually after the migration. 

articles/service-bus-messaging/service-bus-outages-disasters.md

@@ -23,7 +23,7 @@ Service Bus **premium** tier supports geo-disaster recovery, at the namespace le
 
 ### Availability zones
 
-The Service Bus **premium** tier supports [availability Zones](../availability-zones/az-overview.md), providing fault-isolated locations within the same Azure region. Service Bus manages three copies of messaging store (1 primary and 2 secondary). Service Bus keeps all three copies in sync for data and management operations. If the primary copy fails, one of the secondary copies is promoted to primary with no perceived downtime. If applications see transient disconnects from Service Bus, the retry logic in the SDK will automatically reconnect to Service Bus. 
+The Service Bus **premium** tier supports [availability Zones](../availability-zones/az-overview.md), providing fault-isolated locations within the same Azure region. Service Bus manages three copies of messaging store (1 primary and 2 secondary). Service Bus keeps all three copies in sync for data and management operations. If the primary copy fails, one of the secondary copies is promoted to primary with no perceived downtime. If applications see transient disconnects from Service Bus, the [retry logic](/azure/architecture/best-practices/retry-service-specific#service-bus) in the SDK will automatically reconnect to Service Bus. 
 
 When you use availability zones, **both metadata and data (messages)** are replicated across data centers in the availability zone. 
 

articles/service-bus-messaging/service-bus-performance-improvements.md

@@ -28,7 +28,7 @@ Service Bus offers various pricing tiers. It's recommended to pick the appropria
 > [!NOTE]
 > If the right tier is not picked, there is a risk of overwhelming the Service Bus namespace which may lead to [throttling](service-bus-throttling.md).
 >
-> Throttling does not lead to loss of data. Applications leveraging the Service Bus SDK can utilize the default retry policy to ensure that the data is eventually accepted by Service Bus.
+> Throttling does not lead to loss of data. Applications leveraging the Service Bus SDK can utilize the default [retry policy](/azure/architecture/best-practices/retry-service-specific#service-bus) to ensure that the data is eventually accepted by Service Bus.
 >
 
 ### Calculating throughput for Premium

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

@@ -21,7 +21,7 @@ Here are the various exceptions/errors that are surfaced through the Azure Resou
 
 | Error code | Error sub code | Error message | Description | Recommendation |
 | ---------- | ------------- | ------------- | ----------- | -------------- |
-| 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 </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 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. 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. | 
@@ -32,7 +32,7 @@ Here are the various exceptions/errors that are surfaced through the Azure Resou
 | Bad Request | 40000 | Sub code=40000. 'URI_PATH' contains character(s) that isn't allowed by Service Bus. Entity segments can contain only letters, numbers, periods(.), hyphens(-), and underscores(_). | Entity segments can contain only letters, numbers, periods(.), hyphens(-), and underscores(_). Any other characters cause the request to fail. | Ensure that there are no invalid characters in the URI Path. |
 | Bad Request | 40000 | Sub code=40000. Bad request. To know more visit `https://aka.ms/sbResourceMgrExceptions`. TrackingId:00000000-0000-0000-0000-00000000000000_000, SystemTracker:contososbusnamesapce.servicebus.windows.net:myqueue, Timestamp:yyyy-mm-ddThh:mm:ss | This error occurs when you try to create a queue in a non-premium tier namespace with a value set to the property `maxMessageSizeInKilobytes`. This property can only be set for queues in the premium namespace. |
 | Bad Request | 40300 | Sub code=40300. The maximum number of resources of type `EnablePartioning == true` has been reached or exceeded. | There's a limit on number of partitioned entities per namespace. See [Quotas and limits](service-bus-quotas.md). | |
-| Bad Request | 40400 | Sub code=40400. The auto forwarding destination entity doesn't exist. | The destination for the autoforwarding destination entity doesn't exist. | The destination entity (queue or topic), must exist before the source is created. Retry after creating the destination entity. |
+| Bad Request | 40400 | Sub code=40400. The auto forwarding destination entity doesn't exist. | The destination for the autoforwarding destination entity doesn't exist. | The destination entity (queue or topic), must exist before the source is created. [Retry](/azure/architecture/best-practices/retry-service-specific#service-bus) after creating the destination entity. |
 
 ## Error code: 429
 

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

@@ -53,7 +53,7 @@ The request was terminated because the entity is being throttled. Error code: 50
 
 ### 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 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 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. 
 
 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.
 
@@ -95,7 +95,7 @@ Azure Service Bus is optimized for persistence, we ensure that all the data sent
 
 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 of the Service Bus SDK ensures that the request is eventually processed.
+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
 

articles/service-bus-messaging/service-bus-troubleshooting-guide.md

@@ -62,7 +62,7 @@ The following steps may help you with troubleshooting connectivity/certificate/t
 Backend service upgrades and restarts may cause these issues in your applications.
 
 ### Resolution
-If the application code uses SDK, the retry policy is already built in and active. The application will reconnect without significant impact to the application/workflow.
+If the application code uses SDK, the [retry policy](/azure/architecture/best-practices/retry-service-specific#service-bus) is already built in and active. The application will reconnect without significant impact to the application/workflow.
 
 ## Unauthorized access: Send claims are required