Merge pull request #272991 from flang-msft/fxl---Github-issue---Enabling-ForceReconnect-with-StackExchange.Redis-118408

Fxl---GitHub issue-enabling force reconnect with stack exchange.redis 118408

Author: prmerger-automator[bot]

articles/azure-cache-for-redis/cache-best-practices-connection.md

@@ -7,7 +7,7 @@ author: flang-msft
 ms.service: cache
 ms.custom: linux-related-content
 ms.topic: conceptual
-ms.date: 09/29/2023
+ms.date: 04/22/2024
 ms.author: franlanglois
 ---
 
@@ -31,18 +31,22 @@ We recommend these TCP settings:
 
 |Setting  |Value |
 |---------|---------|
-| *net.ipv4.tcp_retries2*   | 5 |
+| `net.ipv4.tcp_retries2`   | 5 |
 
-For more information about the scenario, see [Connection does not re-establish for 15 minutes when running on Linux](https://github.com/StackExchange/StackExchange.Redis/issues/1848#issuecomment-913064646). While this discussion is about the StackExchange.Redis library, other client libraries running on Linux are affected as well. The explanation is still useful and you can generalize to other libraries.
+For more information about the scenario, see [Connection does not re-establish for 15 minutes when running on Linux](https://github.com/StackExchange/StackExchange.Redis/issues/1848#issuecomment-913064646). While this discussion is about the _StackExchange.Redis_ library, other client libraries running on Linux are affected as well. The explanation is still useful and you can generalize to other libraries.
 
 ## Using ForceReconnect with StackExchange.Redis
 
-In rare cases, StackExchange.Redis fails to reconnect after a connection is dropped. In these cases, restarting the client or creating a new `ConnectionMultiplexer` fixes the issue. We recommend using a singleton `ConnectionMultiplexer` pattern while allowing apps to force a reconnection periodically. Take a look at the quickstart sample project that best matches the framework and platform your application uses. You can see an example of this code pattern in our [quickstarts](https://github.com/Azure-Samples/azure-cache-redis-samples).
+In rare cases, _StackExchange.Redis_ fails to reconnect after a connection is dropped. In these cases, restarting the client or creating a new `ConnectionMultiplexer` fixes the issue. We recommend using a singleton `ConnectionMultiplexer` pattern while allowing apps to force a reconnection periodically. Take a look at the quickstart sample project that best matches the framework and platform your application uses. You can see an example of this code pattern in our [quickstarts](https://github.com/Azure-Samples/azure-cache-redis-samples).
 
 Users of the `ConnectionMultiplexer` must handle any `ObjectDisposedException` errors that might occur as a result of disposing the old one.
 
 Call `ForceReconnectAsync()` for `RedisConnectionExceptions` and `RedisSocketExceptions`. You can also call `ForceReconnectAsync()` for `RedisTimeoutExceptions`, but only if you're using generous `ReconnectMinInterval` and `ReconnectErrorThreshold`. Otherwise, establishing new connections can cause a cascade failure on a server that's timing out because it's already overloaded.
 
+In an ASP.NET application, you can use integrated implementation in the _Microsoft.Extensions.Caching.StackExchangeRedis_ package instead of using the _StackExchange.Redis_ package directly. If you're using _Microsoft.Extensions.Caching.StackExchangeRedis_ in an ASP.NET application rather than using _StackExchange.Redis_ directly, you can set the `UseForceReconnect` property to true:
+
+   `Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true`
+
 ## Configure appropriate timeouts
 
 Two timeout values are important to consider in connection resiliency: [connect timeout](#connect-timeout) and [command timeout](#command-timeout).
@@ -51,7 +55,7 @@ Two timeout values are important to consider in connection resiliency: [connect
 
 The `connect timeout` is the time your client waits to establish a connection with Redis server. Configure your client library to use a `connect timeout` of five seconds, giving the system sufficient time to connect even under higher CPU conditions.
 
-A small `connection timeout` value doesn't guarantee a connection is established in that time frame. If something goes wrong (high client CPU, high server CPU, and so on), then a short `connection timeout` value causes the connection attempt to fail. This behavior often makes a bad situation worse. Instead of helping, shorter timeouts aggravate the problem by forcing the system to restart the process of trying to reconnect, which can lead to a *connect -> fail -> retry* loop.
+A small `connection timeout` value doesn't guarantee a connection is established in that time frame. If something goes wrong (high client CPU, high server CPU, and so on), then a short `connection timeout` value causes the connection attempt to fail. This behavior often makes a bad situation worse. Instead of helping, shorter timeouts aggravate the problem by forcing the system to restart the process of trying to reconnect, which can lead to a _connect -> fail -> retry_ loop.
 
 ### Command timeout
 
@@ -66,7 +70,7 @@ Avoid creating many connections at the same time when reconnecting after a conne
 If you're reconnecting many client instances, consider staggering the new connections to avoid a steep spike in the number of connected clients.
 
 > [!NOTE]
-> When you use the `StackExchange.Redis` client library, set `abortConnect` to `false` in your connection string.  We recommend letting the `ConnectionMultiplexer` handle reconnection. For more information, see [StackExchange.Redis best practices](./cache-management-faq.yml#stackexchangeredis-best-practices).
+> When you use the _StackExchange.Redis_ client library, set `abortConnect` to `false` in your connection string.  We recommend letting the `ConnectionMultiplexer` handle reconnection. For more information, see [_StackExchange.Redis_ best practices](./cache-management-faq.yml#stackexchangeredis-best-practices).
 
 ## Avoid leftover connections
 

articles/azure-cache-for-redis/cache-overview.md

@@ -79,7 +79,7 @@ Consider the following options when choosing an Azure Cache for Redis tier:
 - **High availability**: Azure Cache for Redis provides multiple [high availability](cache-high-availability.md) options. It guarantees that a Standard, Premium, or Enterprise cache is available according to our [SLA](https://azure.microsoft.com/support/legal/sla/cache/v1_0/). The SLA only covers connectivity to the cache endpoints. The SLA doesn't cover protection from data loss. We recommend using the Redis data persistence feature in the Premium and Enterprise tiers to increase resiliency against data loss.
 - **Data persistence**: The Premium and Enterprise tiers allow you to persist the cache data to an Azure Storage account and a Managed Disk respectively. Underlying infrastructure issues might result in potential data loss. We recommend using the Redis data persistence feature in these tiers to increase resiliency against data loss. Azure Cache for Redis offers both RDB and AOF (preview) options. Data persistence can be enabled through Azure portal and CLI. For the Premium tier, see [How to configure persistence for a Premium Azure Cache for Redis](cache-how-to-premium-persistence.md).
 - **Network isolation**: Azure Private Link and Virtual Network (VNet) deployments provide enhanced security and traffic isolation for your Azure Cache for Redis. VNet allows you to further restrict access through network access control policies. For more information, see [Azure Cache for Redis with Azure Private Link](cache-private-link.md) and [How to configure Virtual Network support for a Premium Azure Cache for Redis](cache-how-to-premium-vnet.md).
-- **Redis Modules**: Enterprise tiers support [RediSearch](Link https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/search/), [RedisBloom](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/bloom/), [RedisTimeSeries](https://docs.redis.com/latest/modules/redistimeseries/), and [RedisJSON](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/json/). These modules add new data types and functionality to Redis.
+- **Redis Modules**: Enterprise tiers support [RediSearch](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/search/), [RedisBloom](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/bloom/), [RedisTimeSeries](https://docs.redis.com/latest/modules/redistimeseries/), and [RedisJSON](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/json/). These modules add new data types and functionality to Redis.
 
 You can scale your cache from the Basic tier up to Premium after it has been created. Scaling down to a lower tier isn't supported currently. For step-by-step scaling instructions, see [How to Scale Azure Cache for Redis](cache-how-to-scale.md) and [How to scale - Basic, Standard, and Premium tiers](cache-how-to-scale.md#how-to-scale---basic-standard-and-premium-tiers).