Subscriptions are not always restored properly when reconnecting

[DavidZidar]

The internal class ConnectionMultiplexer.Subscription has logic that is supposed to ensure
that subscriptions are restored when reconnecting, however there seems to be a race condition
regarding in which order unsubscribe/subscribe commands are sent.

Sometimes the client resubscribes as expected but then, several seconds later, it may unsubscribe itself and thus forever be unsubscribed.

I find it a bit suspicious that the Validate-method sends unsubscribe and subscribe
commands using CommandFlags.FireAndForget. The order of these commands is very important but
is the order really preserved when using fire and forget?

Also, this may be unrelated, but it seems to me that there is a Dispose-call missing in PhysicalBridge.OnDisconnected around line 346. This strange unsubscribe-behaviour seems to completely disappear when I dispose the physical connection on disconnect.

[ghost]

I'm observing the same issue using Amazon Redis (2.8) Elasticache. My client subscriptions never restore if I restart the Redis server. On disconnect I tried destroying the multiplexer and recreating & re-subscribing, but oddly that didn't help. Also tried your physical.dispose() suggestion - no help. Only thing that restores subscriptions is to restart my client application.

[andysinclair]

I'm experiencing the same issue; has anybody made any progress on working out why subscriptions are not restored on a reconnect?

[mail278]

I have the same problem and I can simulate it easily. Redis server disconnects slow clients (e.g. clients that overcome 8MB buffer limit). If send a lot of data in one application and pause receiving in other (I press pause in Visual Studio) I get disconnected and then reconnected but subscriptions are no longer valid.

Code 1: sender (flooder)

   using (var con = ConnectionMultiplexer.Connect("127.0.0.1"))
      {
        var data = File.ReadAllBytes(@"c:\bigfile"); // file should be cca 100kB large

        var sub = con.GetSubscriber();

        new Action(() =>
          {
            while (true)
            {

              sub.Publish("test", data, CommandFlags.FireAndForget);

              System.Threading.Thread.Sleep(1);
            }
          }).BeginInvoke(null, null);

        Console.ReadKey();
      }

Code 2: receiver

using (var con = ConnectionMultiplexer.Connect("127.0.0.1"))
      {
        var sub = con.GetSubscriber();

        sub.Subscribe("test", (c, v) =>
        {
          Console.WriteLine("Got notification: " + DateTime.Now);
        });

        // Pause VS now for about 10 seconds till server disconnects you, then unpause
        Console.ReadKey();
      }

[mail278]

Ok, strange thing - version 1.0.488 from the 5.november 2015 works fine (with my example). So this is probably different problem - still valid for last version though.

[NickCraver]

These issues were fixed in later versions of the lib, but I missed the duplicate issue - my fault. Just closing out to cleanup here, but the re-subscription logic is much more resilient now and we're no longer seeing reports of it in 1.2.6.