How does ConnectionMultiplexer deal with disconnects?

Question

The Basic Usage documentation for StackExchange.Redis explains that the ConnectionMultiplexer is long-lived and is expected to be reused.

But what about when the connection to the server is broken? Does ConnectionMultiplexer automatically reconnect, or is it necessary to write code as in this answer (quoting that answer):

        if (RedisConnection == null || !RedisConnection.IsConnected)
        {
            RedisConnection = ConnectionMultiplexer.Connect(...);
        }
        RedisCacheDb = RedisConnection.GetDatabase();

Is the above code something good to handle recovery from disconnects, or would it actually result in multiple ConnectionMultiplexer instances? Along the same lines, how should the IsConnected property be interpreted?

[Aside: I believe the above code is a pretty bad form of lazy initialization, particularly in multithreaded environments - see Jon Skeet's article on Singletons].

score 32 · Accepted Answer · edited Aug 12 '16 at 20:59

32

Here is the pattern recommended by the Azure Redis Cache team:

private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() => {
    return ConnectionMultiplexer.Connect("mycache.redis.cache.windows.net,abortConnect=false,ssl=true,password=...");
});

public static ConnectionMultiplexer Connection {
    get {
        return lazyConnection.Value;
    }
}

A few important points:

It uses Lazy<T> to handle thread-safe initialization
It sets "abortConnect=false", which means if the initial connect attempt fails, the ConnectionMultiplexer will silently retry in the background rather than throw an exception.
It does not check the IsConnected property, since ConnectionMultiplexer will automatically retry in the background if the connection is dropped.

edited Aug 12 '16 at 20:59

ranieuwe

2,158
1
23
30

answered Mar 02 '15 at 23:15

Mike Harder

1,535
13
12

Do you have a reference for the recommendation? I did find their MVC movie app example, but it would be helpful to have more background from the source. Here's what I found: http://azure.microsoft.com/blog/2014/06/05/mvc-movie-app-with-azure-redis-cache-in-15-minutes/ – GaTechThomas Mar 03 '15 at 17:59
It seems that this would be the place to go: https://msdn.microsoft.com/en-us/library/dn690521.aspx – GaTechThomas Mar 03 '15 at 18:50
Current link seems to be https://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-use-azure-redis-cache/#connect-to-the-cache – ranieuwe Aug 12 '16 at 17:42
So is this pattern proper-way ? – sabiland Sep 07 '16 at 10:52
Old post but do you not need the isThreadSafe parameter set to true? as in: public Lazy(Func valueFactory, bool isThreadSafe); – MX313 Oct 13 '20 at 15:09
looks like in my case it is not retrying. can someone check https://stackoverflow.com/questions/65261761/problem-in-lazy-connection-logic-in-stackexchenage-redis – Kamran Shahid Dec 13 '20 at 09:54

score 1 · Answer 2 · answered Mar 01 '15 at 10:11

Yes, you need that type of verification in order to fix broken connections. Some thread safety should also be factored in as well. This is how I usually do this:

private static ConnectionMultiplexer _redis;
private static readonly Object _multiplexerLock = new Object();

private void ConnectRedis()
{
    try
    {
        _redis = ConnectionMultiplexer.Connect("...<connection string here>...");
    }
    catch (Exception ex)
    {
        //exception handling goes here
    }
}


private ConnectionMultiplexer RedisMultiplexer
{
    get
    {
        lock (_multiplexerLock)
        {
            if (_redis == null || !_redis.IsConnected)
            {
                ConnectRedis();
            }
            return _redis;
        }
    }
}

Then I use the RedisMultiplexer property everywhere I need to call the Redis endpoint. I don't usually store the result of the GetDatabase() call because the documentation says it's a pretty lightweight call.

A big problem with this approach is that connections will be leaked until the ConnectionMultiplexer instances are cleaned up the CLR garbage collector. If the cache is under heavy load it's possible to hit the 10k connection limit. There's also no good way to call Dispose() on the old ConnectionMultiplexer, since another thread could still be trying to use it. The best approach we have found is to ignore the IsConnected property and let ConnectionMultiplexer retry the connection on its own. — Mike Harder, Mar 02 '15 at 23:21
@MikeHarder I had this suspicion, which is why I asked the question. Thanks for confirming and clarifying. — Gigi, Mar 03 '15 at 09:22

How does ConnectionMultiplexer deal with disconnects?

2 Answers2

Linked