An application is using StackExchange.Redis to connect to their Redis instance and everything is working fine until suddenly exceptions like this start happening.
It was not possible to connect to the redis server(s); to create a disconnected multiplexer, disable AbortOnConnectFail.
at StackExchange.Redis.ConnectionMultiplexer.ConnectImpl(Func`1 multiplexerFactory, TextWriter log)
at MyApp.Web.Redis.StackExchangeClientConnection..ctor(ProviderConfiguration configuration)
at MyApp.Web.Data.GetInventoryData()
Most often this is caused by some type of network blip that occurs where connectivity is briefly lost between the client and the server. StackExchange.Redis has a setting named AbortOnConnectFail that controls how it handles connectivity errors like this. The default value for this setting is "True", meaning that it will not reconnect automatically in some cases (like the one I described above).
Note:
If you are using StackExchange.Redis version 1.1.* (or newer) AND you are hitting an Azure Redis instance, then AbortConnectFail is false by default. However, my personal recommendation would be to set this configuration option explicitly regardless.
Setting AbortOnConnectFail to false will tell StackExchange.Redis to automatically reconnect in the background when the connection is lost for any reason.
Example using ConfigurationOptions class:
public static ConfigurationOptions GetConfiguration(string host, bool
ssl, string accessKey, string clientName)
{
var configuration = ConfigurationOptions.Parse(host);
configuration.Ssl = ssl;
configuration.ClientName = clientName;
configuration.AbortOnConnectFail = false;
configuration.Password = accessKey; return configuration;
}
Example using a Connection String:
var connectionString = "mycache.redis.cache.windows.net,abortConnect=false, ssl=true,password=..."
ConnectionMultiplexer.Connect(connectionString);
Some systems have more advanced requirements, such as using a pool of ConnectionMultiplexers, and it is perfectly fine for such apps to make the decision to take ownership of the connection management. For most of the customers that I work with on these types of issues, setting abortConnect to false greatly improves the behavior and is sufficient.