Merge pull request #204826 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/container-instances/container-instances-vnet.md

@@ -59,7 +59,7 @@ When you deploy to a new virtual network by using this method, the deployment ca
 
 To deploy a container group to an existing virtual network:
 
-1. Create a subnet within your existing virtual network, use an existing subnet in which a container group is already deployed, or use an existing subnet emptied of *all* other resources
+1. Create a subnet within your existing virtual network, use an existing subnet in which a container group is already deployed, or use an existing subnet emptied of *all* other resources and configuration.
 1. Deploy a container group with [az container create][az-container-create] and specify one of the following:
    * Virtual network name and subnet name
    * Virtual network resource ID and subnet resource ID, which allows using a virtual network from a different resource group

articles/open-datasets/dataset-oj-sales-simulated.md

@@ -56,7 +56,7 @@ The data contains weekly sales of orange juice over 121 weeks. There are 3,991 s
 ```python
 from azureml.core.workspace import Workspace
 ws = Workspace.from_config()
-datastore = ws.get_default_config()
+datastore = ws.get_default_datastore()
 ```
 
 ```python
@@ -203,4 +203,4 @@ if sys.platform == 'linux':
 
 ## Next steps
 
-View the rest of the datasets in the [Open Datasets catalog](dataset-catalog.md).
+View the rest of the datasets in the [Open Datasets catalog](dataset-catalog.md).

articles/service-fabric/service-fabric-concepts-partitioning.md

@@ -121,7 +121,7 @@ As we literally want to have one partition per letter, we can use 0 as the low k
 2. In the **New Project** dialog box, choose the Service Fabric application.
 3. Call the project "AlphabetPartitions".
 4. In the **Create a Service** dialog box, choose **Stateful** service and call it "Alphabet.Processing".
-5. Set the number of partitions. Open the Applicationmanifest.xml file located in the ApplicationPackageRoot folder of the AlphabetPartitions project and update the parameter Processing_PartitionCount to 26 as shown below.
+5. Set the number of partitions. Open the ApplicationManifest.xml file located in the ApplicationPackageRoot folder of the AlphabetPartitions project and update the parameter Processing_PartitionCount to 26 as shown below.
 
     ```xml
     <Parameter Name="Processing_PartitionCount" DefaultValue="26" />

articles/service-fabric/service-fabric-reliable-actors-enumerate.md

@@ -53,6 +53,41 @@ do
 while (continuationToken != null);
 ```
 
+While the code above will retrieve all the actors in a given partition, occasionally the need will arise to query the IDs of all actors (active or inactive) across each partition. This should be done by exception as it's quite a heavy task.
+
+The following example demonstrates how to query the partitions of the service and iterate through each in combination with the above example to produce a list of all the active and inactive actors in the service across the Service Fabric application:
+
+
+```csharp
+
+var serviceName = new Uri("fabric:/MyApp/MyService");
+
+//As the FabricClient is expensive to create, it should be shared as much as possible
+FabricClient fabricClient = new();
+
+//List each of the service's partitions
+ServicePartitionList partitions = await fabricClient.QueryManager.GetPartitionListAsync(serviceName);
+
+List<Guid> actorIds = new();
+
+foreach(var partition in partitions)
+{
+    //Retrieve the partition information
+    Int64RangePartitionInformation partitionInformation = (Int64RangePartitionInformation)partition.PartitionInformation; //Actors are restricted to the uniform Int64 scheme per https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction#distribution-and-failover
+    IActorService actorServiceProxy = ActorServiceProxy.Create(serviceName, partitionInformation.LowKey);
+    
+    ContinuationToken? continuationToken = null;
+    
+    do 
+    {
+        var page = await actorServiceProxy.GetActorsAsync(continuationToken, cancellationToken);
+        actorIds.AddRange(page.Items.Select(actor => actor.ActorId.GetGuidId());
+        continuationToken = page.ContinuationToken;
+    } while (continuationToken != null);
+}
+
+return actorIds;
+```
 
 
 ## Next steps

articles/service-fabric/service-fabric-reliable-services-notifications.md

@@ -18,8 +18,8 @@ Common reasons for using notifications are:
 * Building materialized views, such as secondary indexes or aggregated filtered views of the replica's state. An example is a sorted index of all keys in Reliable Dictionary.
 * Sending monitoring data, such as the number of users added in the last hour.
 
-Notifications are fired as part of applying operations. 
-Because of that, notifications should be handled as fast as possible, and synchronous events shouldn't include any expensive operations.
+Notifications are fired as a part of applying operations. On a primary replica, operations are applied after quorum acknowledgment as a part of `transaction.CommitAsync()` or `this.StateManager.GetOrAddAsync()`. On secondary replicas, operations are applied at replication queue data processing. Because of that, notifications should be handled as fast as possible, and synchronous events shouldn't include any expensive operations. Otherwise, it could negatively impact transaction processing time as well as replica build-ups.
+
 
 ## Reliable State Manager notifications
 Reliable State Manager provides notifications for the following events:
@@ -212,7 +212,7 @@ Here are some things to keep in mind:
 * Because notifications are fired as part of the applying operations, clients see only notifications for locally committed operations. And because operations are guaranteed only to be locally committed (in other words, logged), they might or might not be undone in the future.
 * On the redo path, a single notification is fired for each applied operation. This means that if transaction T1 includes Create(X), Delete(X), and Create(X), you'll get one notification for the creation of X, one for the deletion, and one for the creation again, in that order.
 * For transactions that contain multiple operations, operations are applied in the order in which they were received on the primary replica from the user.
-* As part of processing false progress, some operations might be undone. Notifications are raised for such undo operations, rolling the state of the replica back to a stable point. One important difference of undo notifications is that events that have duplicate keys are aggregated. For example, if transaction T1 is being undone, you'll see a single notification to Delete(X).
+* As part of processing false progress, some operations might be undone on secondary replicas. Notifications are raised for such undo operations, rolling the state of the replica back to a stable point. One important difference of undo notifications is that events that have duplicate keys are aggregated. For example, if transaction T1 is being undone, you'll see a single notification to Delete(X).
 
 ## Next steps
 * [Reliable Collections](service-fabric-work-with-reliable-collections.md)