Merge pull request #269376 from spelluru/sbusgitissues

Service Bus Git and supportability issues

Author: prmerger-automator[bot]

articles/service-bus-messaging/service-bus-auto-forwarding.md

@@ -1,5 +1,5 @@
 ---
-title: Auto-forwarding Azure Service Bus messaging entities
+title: Autoforwarding Azure Service Bus messaging entities
 description: This article describes how to chain an Azure Service Bus queue or subscription to another queue or topic.
 ms.topic: article
 ms.date: 07/27/2022
@@ -18,12 +18,12 @@ The destination entity must exist at the time the source entity is created. If t
 ## Scenarios
 
 ### Scale out an individual topic
-You can use autoforwarding to scale out an individual topic. Service Bus limits the [number of subscriptions on a given topic](service-bus-quotas.md) to 2,000. You can accommodate additional subscriptions by creating second-level topics. Even if you aren't bound by the Service Bus limitation on the number of subscriptions, adding a second level of topics can improve the overall throughput of your topic.
+You can use autoforwarding to scale out an individual topic. Service Bus limits the [number of subscriptions on a given topic](service-bus-quotas.md) to 2,000. You can accommodate more subscriptions by creating second-level topics. Even if you aren't bound by the Service Bus limitation on the number of subscriptions, adding a second level of topics can improve the overall throughput of your topic.
 
 ![Diagram of an autoforwarding scenario showing a message processed through an Orders Topic that can branch to any of three second-level Orders Topics.][0]
 
 ### Decouple message senders from receivers
-You can also use autoforwarding to decouple message senders from receivers. For example, consider an ERP system that consists of three modules: order processing, inventory management, and customer relations management. Each of these modules generates messages that are enqueued into a corresponding topic. Alice and Bob are sales representatives that are interested in all messages that relate to their customers. To receive those messages, Alice and Bob each create a personal queue and a subscription on each of the ERP topics that automatically forward all messages to their queue.
+You can also use autoforwarding to decouple message senders from receivers. For example, consider an Enterprise Resource Planning (ERP) system that consists of three modules: order processing, inventory management, and customer relations management. Each of these modules generates messages that are enqueued into a corresponding topic. Alice and Bob are sales representatives that are interested in all messages that relate to their customers. To receive those messages, Alice and Bob each create a personal queue and a subscription on each of the ERP topics that automatically forward all messages to their queue.
 
 ![Diagram of an autoforwarding scenario showing three processing modules sending messages through three corresponding topics to two separate queues.][1]
 
@@ -37,14 +37,16 @@ If Alice goes on vacation, her personal queue, rather than the ERP topic, fills
 
 ## Autoforwarding considerations
 
+- Service Bus doesn't allow creating a message receiver on a source entity with autoforwarding enabled.
 - If the destination entity accumulates too many messages and exceeds the quota, or the destination entity is disabled, the source entity adds the messages to its [dead-letter queue](service-bus-dead-letter-queues.md) until there's space in the destination (or the entity is re-enabled). Those messages continue to live in the dead-letter queue, so you must explicitly receive and process them from the dead-letter queue.
 - When chaining together individual topics to obtain a composite topic with many subscriptions, it's recommended that you have a moderate number of subscriptions on the first-level topic and many subscriptions on the second-level topics. For example, a first-level topic with 20 subscriptions, each of them chained to a second-level topic with 200 subscriptions, allows for higher throughput than a first-level topic with 200 subscriptions, each chained to a second-level topic with 20 subscriptions.
 - Service Bus bills one operation for each forwarded message. For example, sending a message to a topic with 20 subscriptions, each of them configured to autoforward messages to another queue or topic, is billed as 21 operations if all first-level subscriptions receive a copy of the message.
 - To create a subscription that is chained to another queue or topic, the creator of the subscription must have **Manage** permissions on both the source and the destination entity. Sending messages to the source topic only requires **Send** permissions on the source topic.
-- Don't create a chain that exceeds four hops. Messages that exceed four hops are dead-lettered.
+- Don't create a chain that exceeds four hops. Messages that exceed four hops are dead-lettered. The hop count of a message is incremented when a message is autoforwarded from one queue or topic to another queue or topic. The hop count of a message can also be incremented in the [send via](service-bus-transactions.md#transfers-and-send-via) scenario in which a message is sent via a transfer queue.
 - Autoforwarding isn't supported for session-enabled queues or subscriptions. 
 - Source queue tries to forward messages to the destination entity in the same order it received, but the destination could be a topic that doesn't support ordering. If either the source or destination entity is a partitioned entity, order isn't guaranteed.
 
+
 ## Next steps
 To learn how to enable or disable auto forwarding in different ways (Azure portal, PowerShell, CLI, Azure Resource Management template, etc.), see [Enable auto forwarding for queues and subscriptions](enable-auto-forward.md).
 

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

@@ -32,7 +32,7 @@ The Geo-Disaster recovery feature ensures that the entire configuration of a nam
     - Enable auto scale
     - Disable local authentication
 - Pairing a [partitioned namespace](enable-partitions-premium.md) with a non-partitioned namespace isn't supported.
-- If `AutoDeleteOnIdle` is turned on an entity, the entity might not be present in the secondary namespace when the failover occurs. When the secondary becomes primary the last access status, which is not part of the metadata, won't be available to the new primary and entity may be deleted as part of `AutoDeleteOnIdle` clean up.
+- If `AutoDeleteOnIdle` is enabled for an entity, the entity might not be present in the secondary namespace when the failover occurs. When the secondary becomes primary the last access status, which is not part of the metadata, won't be available to the new primary and entity may be deleted as part of `AutoDeleteOnIdle` clean up.
 
 > [!TIP]
 > For replicating the contents of queues and topic subscriptions and operating corresponding namespaces in active/active configurations to cope with outages and disasters, don't lean on this Geo-disaster recovery feature set, but follow the [replication guidance](service-bus-federation-overview.md).  
@@ -197,7 +197,7 @@ If pairing between primary and secondary namespace already exists, private endpo
 ### Recommended configuration
 When creating a disaster recovery configuration for your application and Service Bus, you must create private endpoints for both primary and secondary Service Bus namespaces against virtual networks hosting both primary and secondary instances of your application.
 
-Let's say you have two virtual networks: VNET-1, VNET-2 and these primary and second namespaces: `ServiceBus-Namespace1-Primary`, `ServiceBus-Namespace2-Secondary`. You need to do the following steps: 
+Let's say you have two virtual networks: VNET-1, VNET-2 and these primary and secondary namespaces: `ServiceBus-Namespace1-Primary`, `ServiceBus-Namespace2-Secondary`. You need to do the following steps: 
 
 - On `ServiceBus-Namespace1-Primary`, create two private endpoints that use subnets from VNET-1 and VNET-2
 - On `ServiceBus-Namespace2-Secondary`, create two private endpoints that use the same subnets from VNET-1 and VNET-2