7

I am using a Redis pubsub channel to send messages from a pool of worker processes to my ASP.NET application. When a message is received, my application forwards the message to a client's browser with SignalR.

I found this solution to maintaining an open connection to Redis, but it doesn't account for subscriptions when it recreates the connection.

I'm currently handling Redis pubsub messages in my Global.asax file:

public class Application : HttpApplication
{
    protected void Application_Start()
    {
        var gateway = Resolve<RedisConnectionGateway>();
        var connection = gateway.GetConnection();
        var channel = connection.GetOpenSubscriberChannel();

        channel.PatternSubscribe("workers:job-done:*", OnExecutionCompleted);
    }

    /// <summary>
    /// Handle messages received from workers through Redis.</summary>
    private static void OnExecutionCompleted(string key, byte[] message)
    {
        /* forwarded the response to the client that requested it */
    }
}

The problem occurs when the current RedisConnection is closed for whatever reason. The simplest solution the problem would be to fire an event from the RedisConnectionGateway class when the connection has been reset, and resubscribe using a new RedisSubscriberChannel. However, any messages published to the channel while the connection is being reset would be lost.

Are there any examples of recommended ways to handle this situation?

Community
  • 1
  • 1
Justin Rusbatch
  • 3,992
  • 2
  • 25
  • 43
  • My solution indeed returns a Redis connection if it's open already, or opens one if not. I believe that in "conventional use" the connection will remain open and you won't get it dropped in your PubSub schema. In the rare case of the connection being closed from some reason, you will get a new one, and yes - messages published to the channel while the connection is being reset would be lost. But it's for a very short time, and it doesn't suppose to happen on a regular basis. Anyway, let's have BookSleeve's author highlight on this (CC @marcgravell). – Ofer Zelig Apr 10 '12 at 01:43
  • @OferZelig thanks, but `@someone` doesn't work unless I'm already involved in the post somehow ;p – Marc Gravell Apr 10 '12 at 13:08
  • @MarcGravell I didn't know that; anyway: 1) How can one communicate with another SE user to get his/her attention to something? I mean - inside an SE site, not by checking is profile and go to his/her blog or such; 2) You can implement in SE a feature that identifies this and alerts (an xxx pattern, where xxx is a known SE user name). Thanks! – Ofer Zelig Apr 11 '12 at 08:08
  • SE display-names are not enforced as unique. By design, you can only use `@username` to engage people already involved in a question. In SO, the post is the important unit. – Marc Gravell Apr 11 '12 at 08:17

1 Answers1

8

Yes, if the connection dies (network instability, re-mastering, whatever) then you will need to re-apply any subscriptions you have made. An event to reconnect and resubscribe is pretty normal, and not very different to what we use here on SE/SO (except we typically track more granular subscriptions, and have some wrapper code that handles all that).

Yes, any events published while your connection was broken are gone. That is the nature of redis pub/sub; it does not guarantee delivery to disconnected clients. Either use a tool that does promise this, or use redis to drive a queue instead - pushing/popping to/from opposite ends of a list is usually a reasonable alternative, and ensures nothing is lost (as long as your software doesn't drop it after popping it from the list). If it helps, I have on my list a request to add the blocking pop methods - they totally destroy the multiplexer intent, but they have genuine use in some cases, so I'm not against adding them.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900