Merge pull request #215708 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/azure-resource-manager/bicep/bicep-functions-deployment.md

@@ -176,7 +176,7 @@ The preceding example returns the following object when deployed to global Azure
   "vmImageAliasDoc": "https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/arm-compute/quickstart-templates/aliases.json",
   "resourceManager": "https://management.azure.com/",
   "authentication": {
-    "loginEndpoint": "https://login.windows.net/",
+    "loginEndpoint": "https://login.microsoftonline.com/",
     "audiences": [
       "https://management.core.windows.net/",
       "https://management.azure.com/"

articles/azure-signalr/signalr-overview.md

@@ -70,4 +70,4 @@ There are many different ways to program with Azure SignalR Service, as some of
 
 - **[Scale an ASP.NET Core SignalR App](signalr-concept-scale-aspnet-core.md)** - Integrate Azure SignalR Service with an ASP.NET Core SignalR application to scale out to hundreds of thousands of connections.
 - **[Build serverless real-time apps](signalr-concept-azure-functions.md)** - Use Azure Functions' integration with Azure SignalR Service to build serverless real-time applications in languages such as JavaScript, C#, and Java.
-- **[Send messages from server to clients via REST API](https://github.com/Azure/azure-signalr/blob/dev/docs/rest-api.md)** - Azure SignalR Service provides REST API to enable applications to post messages to clients connected with SignalR Service, in any REST capable programming languages.
+- **[Send messages from server to clients via REST API](signalr-reference-data-plane-rest-api.md)** - Azure SignalR Service provides REST API to enable applications to post messages to clients connected with SignalR Service, in any REST capable programming languages.

articles/service-bus-messaging/service-bus-dotnet-get-started-with-queues.md

@@ -540,8 +540,8 @@ In this section, you'll add code to retrieve messages from the queue.
     // the client that owns the connection and can be used to create senders and receivers
     ServiceBusClient client;
     
-    // the sender used to publish messages to the queue
-    ServiceBusSender sender;
+    // the processor that reads and processes messages from the queue
+    ServiceBusProcessor processor;
     
     // The Service Bus client types are safe to cache and use as a singleton for the lifetime
     // of the application, which is best practice when messages are being published or read

articles/service-fabric/service-fabric-reliable-services-reliable-collections-guidelines.md

@@ -28,6 +28,9 @@ The guidelines are organized as simple recommendations prefixed with the terms *
 * Consider using backup and restore functionality to have disaster recovery.
 * Avoid mixing single entity operations and multi-entity operations (e.g `GetCountAsync`, `CreateEnumerableAsync`) in the same transaction due to the different isolation levels.
 * Do handle InvalidOperationException. User transactions can be aborted by the system for variety of reasons. For example, when the Reliable State Manager is changing its role out of Primary or when a long-running transaction is blocking truncation of the transactional log. In such cases, user may receive InvalidOperationException indicating that their transaction has already been terminated. Assuming, the termination of the transaction was not requested by the user, best way to handle this exception is to dispose the transaction, check if the cancellation token has been signaled (or the role of the replica has been changed), and if not create a new transaction and retry.  
+* Do not apply any parallelism within a transaction.
+* Consider dispose transaction as soon as possible after commit completes (especially if using ConcurrentQueue).
+* Do not perform any blocking code inside a transaction.
 
 Here are some things to keep in mind:
 

articles/virtual-desktop/disaster-recovery-concepts.md

@@ -55,7 +55,7 @@ Another option is an active-active deployment, where you use both sets of infras
 - Have extra session hosts in both active regions, but deallocate them when they aren't needed, which reduces costs.
 - Only provision new infrastructure during disaster recovery and allow affected users to connect to the newly provisioned session hosts. This method requires regular testing with infrastructure-as-code tools so you can deploy the new infrastructure as quickly as possible during a disaster.
 
-## Recommended diaster recovery methods
+## Recommended disaster recovery methods
 
 The disaster recovery methods we recommend are: