1

We are using following code to connect to our caches (in-memory and Redis):

settings .WithSystemRuntimeCacheHandle() .WithExpiration(CacheManager.Core.ExpirationMode.Absolute, defaultExpiryTime) .And .WithRedisConfiguration(CacheManagerRedisConfigurationKey, connectionString) .WithMaxRetries(3) .WithRetryTimeout(100) .WithJsonSerializer() .WithRedisBackplane(CacheManagerRedisConfigurationKey) .WithRedisCacheHandle(CacheManagerRedisConfigurationKey, true) .WithExpiration(CacheManager.Core.ExpirationMode.Absolute, defaultExpiryTime);

It works fine, but sometimes machine is restarted (automatically by Azure where we host it) and after the restart connection to Redis fails with following exception:

Connection to '{connection string}' failed. at CacheManager.Core.BaseCacheManager`1..ctor(String name, ICacheManagerConfiguration configuration) at CacheManager.Core.BaseCacheManager`1..ctor(ICacheManagerConfiguration configuration) at CacheManager.Core.CacheFactory.Build[TCacheValue](String cacheName, Action`1 settings) at CacheManager.Core.CacheFactory.Build(Action`1 settings)

According to Redis FAQ (https://learn.microsoft.com/en-us/azure/redis-cache/cache-faq) part: "Why was my client disconnected from the cache?" it might happen after redeploy.

The question is

  • is there any mechanism to restore the connection after redeploy
  • is anything wrong in way we initialize the connection

We are sure the connection string is OK

michal.jakubeczy
  • 8,221
  • 1
  • 59
  • 63
  • 1
    On app startup, CacheManager will throw that exception if Redis is not available. You can increase the connectionTimeout property though, maybe that helps. You can retry the initialization manually a couple of times... After startup, the connection (if established once) should recover after a Redis server downtime automatically... – MichaC Oct 18 '17 at 19:44

1 Answers1

2

Most clients (including StackExchange.Redis) usually connect / re-connect automatically after a connection break. However, your connect timeout setting needs to be large enough for the re-connect to happen successfully. Remember, you only connect once, so it's alright to give the system enough time to be able to reconnect. Higher connect timeout is especially useful when you have a burst of connections or re-connections after a blip causing CPU to spike and some connections might not happen in time.

In this case, I see RetryTimeout as 100. If this is the Connection timeout, check if this is in milliseconds. 100 milliseconds is too low. You might want to make this more like 10 seconds (remember it's a one time thing, so you want to give it time to be able to connect).

Carl Dacosta
  • 873
  • 4
  • 13
  • sounds like a good idea. but even with low timeout connection should be restored after some time. but in our case happens it never gets restored. do you have any explanation for this? – michal.jakubeczy Oct 17 '17 at 08:54
  • Are you using SignalR? If not, what technology are you using? SignalR has a known issue described here:https://github.com/SignalR/SignalR/issues/4019. Also, make sure you aren't using Basic SKU of Redis - that is a single node and if the OS gets patched, it will be unreachable until the patch completes. – JonCole Oct 17 '17 at 16:15