PR comments

Author: amerjusupovic

articles/azure-app-configuration/enable-dynamic-configuration-aspnet-core.md

@@ -36,11 +36,11 @@ Finish the quickstart: [Create an ASP.NET Core app with App Configuration](./qui
     builder.Configuration.AddAzureAppConfiguration(options =>
     {
         options.Connect(new Uri(endpoint), new DefaultAzureCredential())
-                // Load all keys that start with `TestApp:` and have no label.
-                .Select("TestApp:*", LabelFilter.Null)
-                // Reload configuration if any selected key-values have changed.
-                .ConfigureRefresh(refreshOptions =>
-                    refreshOptions.RegisterAll());
+               // Load all keys that start with `TestApp:` and have no label.
+               .Select("TestApp:*", LabelFilter.Null)
+               // Reload configuration if any selected key-values have changed.
+               .ConfigureRefresh(refreshOptions =>
+                   refreshOptions.RegisterAll());
     });
     ```
 
@@ -100,7 +100,7 @@ You've set up your app to use the [options pattern in ASP.NET Core](/aspnet/core
 
 ## Request-driven configuration refresh
 
-The configuration refresh is triggered by the incoming requests to your web app. No refresh will occur if your app is idle. When your app is active, the App Configuration middleware monitors any keys you registered for refreshing in the `ConfigureRefresh` call. The middleware is triggered upon every incoming request to your app. However, the middleware will only send requests to check the value in App Configuration when the cache expiration time you set has passed.
+The configuration refresh is triggered by the incoming requests to your web app. No refresh will occur if your app is idle. When your app is active, the App Configuration middleware monitors any keys you registered for refreshing in the `ConfigureRefresh` call. The middleware is triggered upon every incoming request to your app. However, the middleware will only send requests to check the value in App Configuration when the refresh interval you set has passed.
 
 - If a request to App Configuration for change detection fails, your app will continue to use the cached configuration. New attempts to check for changes will be made periodically while there are new incoming requests to your app.
 - The configuration refresh happens asynchronously to the processing of your app's incoming requests. It will not block or slow down the incoming request that triggered the refresh. The request that triggered the refresh may not get the updated configuration values, but later requests will get new configuration values.

articles/azure-app-configuration/enable-dynamic-configuration-aspnet-netfx.md

@@ -99,14 +99,14 @@ Add the following key-values to the App Configuration store and leave **Label**
         {
             string endpoint = Environment.GetEnvironmentVariable("Endpoint"); 
             options.Connect(new Uri(endpoint), new DefaultAzureCredential())
-                    // Load all keys that start with `TestApp:` and have no label.
-                    .Select("TestApp:*")
-                    // Reload configuration if any selected key-values have changed.
-                    .ConfigureRefresh(refresh => 
-                    {
-                        refresh.RegisterAll()
-                               .SetRefreshInterval(new TimeSpan(0, 5, 0));
-                    });
+                   // Load all keys that start with `TestApp:` and have no label.
+                   .Select("TestApp:*")
+                   // Reload configuration if any selected key-values have changed.
+                   .ConfigureRefresh(refresh => 
+                   {
+                       refresh.RegisterAll()
+                              .SetRefreshInterval(new TimeSpan(0, 5, 0));
+                   });
             _configurationRefresher = options.GetRefresher();
         });
 
@@ -123,14 +123,14 @@ Add the following key-values to the App Configuration store and leave **Label**
         builder.AddAzureAppConfiguration(options =>
         {
             options.Connect(Environment.GetEnvironmentVariable("ConnectionString"))
-                    // Load all keys that start with `TestApp:` and have no label.
-                    .Select("TestApp:*")
-                    // Reload configuration if any selected key-values have changed.
-                    .ConfigureRefresh(refresh => 
-                    {
-                        refresh.RegisterAll()
-                               .SetRefreshInterval(new TimeSpan(0, 5, 0));
-                    });
+                   // Load all keys that start with `TestApp:` and have no label.
+                   .Select("TestApp:*")
+                   // Reload configuration if any selected key-values have changed.
+                   .ConfigureRefresh(refresh => 
+                   {
+                       refresh.RegisterAll()
+                              .SetRefreshInterval(new TimeSpan(0, 5, 0));
+                   });
             _configurationRefresher = options.GetRefresher();
         });
 
@@ -155,9 +155,9 @@ Add the following key-values to the App Configuration store and leave **Label**
     ```
     Calling the `ConfigureRefresh` method alone won't cause the configuration to refresh automatically. You call the `TryRefreshAsync` method at the beginning of every request to signal a refresh. This design ensures your application only sends requests to App Configuration when it is actively receiving requests. 
 
-    Calling `TryRefreshAsync` is a no-op before the configured cache expiration time elapses, so its performance impact is minimal. When a request is made to App Configuration, as you don't wait on the task, the configuration is refreshed asynchronously without blocking the execution of the current request. The current request may not get the updated configuration values, but subsequent requests will do.
+    Calling `TryRefreshAsync` is a no-op before the configured refresh interval elapses, so its performance impact is minimal. When a request is made to App Configuration, as you don't wait on the task, the configuration is refreshed asynchronously without blocking the execution of the current request. The current request may not get the updated configuration values, but subsequent requests will do.
 
-    If the call `TryRefreshAsync` fails for any reason, your application will continue to use the cached configuration. Another attempt will be made when the configured cache expiration time has passed again, and the `TryRefreshAsync` call is triggered by a new request to your application.
+    If the call `TryRefreshAsync` fails for any reason, your application will continue to use the cached configuration. Another attempt will be made when the configured refresh interval has passed again, and the `TryRefreshAsync` call is triggered by a new request to your application.
 
 ## Use the latest configuration data
 
@@ -268,7 +268,7 @@ Add the following key-values to the App Configuration store and leave **Label**
     | *TestApp:Settings:FontColor*       | *LightGray*                                                  |
     | *TestApp:Settings:Message*         | *Data from Azure App Configuration - now with live updates!* |
 
-1. Refresh the browser page to see the new configuration settings. You may need to refresh more than once for the changes to be reflected or change your cache expiration time to less than 5 minutes. 
+1. Refresh the browser page to see the new configuration settings. You may need to refresh more than once for the changes to be reflected or change your refresh interval to less than 5 minutes. 
 
     ![App refresh local](./media/dotnet-fx-web-app-refresh.png)
 

articles/azure-app-configuration/enable-dynamic-configuration-dotnet-background-service.md

@@ -168,7 +168,7 @@ You use the [.NET command-line interface (CLI)](/dotnet/core/tools/) to create a
     }
     ```
 
-    Calling the `ConfigureRefresh` method alone won't cause the configuration to refresh automatically. You call the `TryRefreshAsync` method from the interface `IConfigurationRefresher` to trigger a refresh. This design is to avoid requests sent to App Configuration even when your application is idle. You can include the `TryRefreshAsync` call where you consider your application active. For example, it can be when you process an incoming message, an order, or an iteration of a complex task. It can also be in a timer if your application is active all the time. In this example, you call `TryRefreshAsync` every time the background service is executed. Note that, even if the call `TryRefreshAsync` fails for any reason, your application will continue to use the cached configuration. Another attempt will be made when the configured cache expiration time has passed and the `TryRefreshAsync` call is triggered by your application activity again. Calling `TryRefreshAsync` is a no-op before the configured cache expiration time elapses, so its performance impact is minimal, even if it's called frequently.
+    Calling the `ConfigureRefresh` method alone won't cause the configuration to refresh automatically. You call the `TryRefreshAsync` method from the interface `IConfigurationRefresher` to trigger a refresh. This design is to avoid requests sent to App Configuration even when your application is idle. You can include the `TryRefreshAsync` call where you consider your application active. For example, it can be when you process an incoming message, an order, or an iteration of a complex task. It can also be in a timer if your application is active all the time. In this example, you call `TryRefreshAsync` every time the background service is executed. Note that, even if the call `TryRefreshAsync` fails for any reason, your application will continue to use the cached configuration. Another attempt will be made when the configured refresh interval has passed and the `TryRefreshAsync` call is triggered by your application activity again. Calling `TryRefreshAsync` is a no-op before the configured refresh interval elapses, so its performance impact is minimal, even if it's called frequently.
 
 ## Build and run the app locally
 

articles/azure-app-configuration/enable-dynamic-configuration-dotnet-core-push-refresh.md

@@ -173,9 +173,9 @@ namespace TestConsole
 }
 ```
 
-The `ProcessPushNotification` method resets the cache expiration to a short random delay. This causes future calls to `RefreshAsync` or `TryRefreshAsync` to re-validate the cached values against App Configuration and update them as necessary. In this example you register to monitor changes to all selected key-values (*TestApp:Settings:Message*) with a cache expiration of one day. This means no request to App Configuration will be made before a day has passed since the last check. By calling  `ProcessPushNotification` your application will send requests to App Configuration in the next few seconds. Your application will load the new configuration values shortly after changes occur in the `App Configuration` store without the need to constantly poll for updates. In case your application misses the change notification for any reason, it will still check for configuration changes once a day.
+The `ProcessPushNotification` method resets the refresh interval to a short random delay. This causes future calls to `RefreshAsync` or `TryRefreshAsync` to re-validate the cached values against App Configuration and update them as necessary. In this example you register to monitor changes to all selected key-values (*TestApp:Settings:Message*) with a refresh interval of one day. This means no request to App Configuration will be made before a day has passed since the last check. By calling  `ProcessPushNotification` your application will send requests to App Configuration in the next few seconds. Your application will load the new configuration values shortly after changes occur in the `App Configuration` store without the need to constantly poll for updates. In case your application misses the change notification for any reason, it will still check for configuration changes once a day.
 
-The short random delay for cache expiration is helpful if you have many instances of your application or microservices connecting to the same App Configuration store with the push model. Without this delay, all instances of your application could send requests to your App Configuration store simultaneously as soon as they receive a change notification. This can cause the App Configuration Service to throttle your store. Cache expiration delay is set to a random number between 0 and a maximum of 30 seconds by default, but you can change the maximum value through the optional parameter `maxDelay` to the `ProcessPushNotification` method.
+The short random delay for refresh interval is helpful if you have many instances of your application or microservices connecting to the same App Configuration store with the push model. Without this delay, all instances of your application could send requests to your App Configuration store simultaneously as soon as they receive a change notification. This can cause the App Configuration Service to throttle your store. refresh interval delay is set to a random number between 0 and a maximum of 30 seconds by default, but you can change the maximum value through the optional parameter `maxDelay` to the `ProcessPushNotification` method.
 
 The `ProcessPushNotification` method takes in a `PushNotification` object containing information about which change in App Configuration triggered the push notification. This helps ensure all configuration changes up to the triggering event are loaded in the following configuration refresh. The `SetDirty` method does not guarantee the change that triggers the push notification to be loaded in an immediate configuration refresh. If you are using the `SetDirty` method for the push model, we recommend using the `ProcessPushNotification` method instead.
 

articles/azure-app-configuration/enable-dynamic-configuration-dotnet-core.md

@@ -50,14 +50,14 @@ builder.AddAzureAppConfiguration(options =>
 {
     string endpoint = Environment.GetEnvironmentVariable("Endpoint"); 
     options.Connect(new Uri(endpoint), new DefaultAzureCredential())            
-            // Load the key-value with key "TestApp:Settings:Message" and no label
-            .Select("TestApp:Settings:Message")
-            // Reload configuration if any selected key-values have changed.
-            .ConfigureRefresh(refresh =>
-            {
-                refresh.RegisterAll()
-                       .SetRefreshInterval(TimeSpan.FromSeconds(10));
-            });
+           // Load the key-value with key "TestApp:Settings:Message" and no label
+           .Select("TestApp:Settings:Message")
+           // Reload configuration if any selected key-values have changed.
+           .ConfigureRefresh(refresh =>
+           {
+               refresh.RegisterAll()
+                      .SetRefreshInterval(TimeSpan.FromSeconds(10));
+            })
 
     _refresher = options.GetRefresher();
 });
@@ -81,7 +81,7 @@ Inside the `ConfigureRefresh` method, you call the `RegisterAll` method to instr
 
 The `SetRefreshInterval` method specifies the minimum time that must elapse before a new request is made to App Configuration to check for any configuration changes. In this example, you override the default expiration time of 30 seconds, specifying a time of 10 seconds instead for demonstration purposes.
 
-Calling the `ConfigureRefresh` method alone won't cause the configuration to refresh automatically. You call the `TryRefreshAsync` method from the interface `IConfigurationRefresher` to trigger a refresh. This design is to avoid requests sent to App Configuration even when your application is idle. You'll want to include the `TryRefreshAsync` call where you consider your application active. For example, it can be when you process an incoming message, an order, or an iteration of a complex task. It can also be in a timer if your application is active all the time. In this example, you call `TryRefreshAsync` every time you press the Enter key. Even if the call `TryRefreshAsync` fails for any reason, your application continues to use the cached configuration. Another attempt is made when the configured cache expiration time has passed and the `TryRefreshAsync` call is triggered by your application activity again. Calling `TryRefreshAsync` is a no-op before the configured cache expiration time elapses, so its performance impact is minimal, even if it's called frequently.
+Calling the `ConfigureRefresh` method alone won't cause the configuration to refresh automatically. You call the `TryRefreshAsync` method from the interface `IConfigurationRefresher` to trigger a refresh. This design is to avoid requests sent to App Configuration even when your application is idle. You'll want to include the `TryRefreshAsync` call where you consider your application active. For example, it can be when you process an incoming message, an order, or an iteration of a complex task. It can also be in a timer if your application is active all the time. In this example, you call `TryRefreshAsync` every time you press the Enter key. Even if the call `TryRefreshAsync` fails for any reason, your application continues to use the cached configuration. Another attempt is made when the configured refresh interval has passed and the `TryRefreshAsync` call is triggered by your application activity again. Calling `TryRefreshAsync` is a no-op before the configured refresh interval elapses, so its performance impact is minimal, even if it's called frequently.
 
 ### Configuration refresh using dependency injection
 
@@ -170,7 +170,7 @@ In the previous code, you're manually saving an instance of `IConfigurationRefre
     ![Quickstart app refresh local](./media/quickstarts/dotnet-core-app-run-refresh.png)
 
     > [!NOTE]
-    > Since the cache expiration time was set to 10 seconds using the `SetRefreshInterval` method while specifying the configuration for the refresh operation, the value for the configuration setting will only be updated if at least 10 seconds have elapsed since the last refresh for that setting.
+    > Since the refresh interval was set to 10 seconds using the `SetRefreshInterval` method while specifying the configuration for the refresh operation, the value for the configuration setting will only be updated if at least 10 seconds have elapsed since the last refresh for that setting.
 
 ## Logging and monitoring