Is a new connection created for each pub/sub channel subscribed?

[shravan2x]

As the title asks, is a new connection created for each pub/sub channel subscribed? How about when publishing to multiple channels?

This might be useful to add to the docs.

[NickCraver]

Nope, no new connections. As the docs already note: you create and use one ConnectionMultiplexer and it handles all this internally. In total there are 2 connections to redis: 1 every non-subscriber operation, and 1 more for subscriber pub/sub operations.

[shravan2x]

Interesting, are more subscriber connections created if the bandwidth is required?

[NickCraver]

@shravan2x No new connections are ever created, only restored if broken. Redis is processing them in a single-threaded-behavior style, and the client must also do so to have the order maintained. From redis's point of view, 2 connections are 2 clients. If we connected twice, we'd just get every message twice, or we'd be randomly choosing how to shard subscriptions and have no real knowledge of how we're balancing. Given the client and server are in the same places respectively, adding a connection isn't going to add more bandwidth unless you're in a high latency/TCP window constrained environment. If that's the case, it'd only matter for very large payloads in which case...lots of bad things are being combined and the situation should really be evaluated at a higher level before this is an issue.

[shravan2x]

This was all really good to know, could it be added to the docs (or am I just missing it somehow)?

[NickCraver]

Sure, we can look at noting the behavior with some doc updates we'll do in 2.0. Tagging it for that pass.

[ericpauley]

Related clarification, when does SubscribeAsync complete, when the command has been sent or when the SUBSCRIBE acknowledgement is received? Using PubSub for key change notifications so I need to wait until SUBSCRIBE is ack'd before fetching initial key status.

Alternatively, give an additional SUBSCRIBE callback, since the same change checking code would need to run on connection drop as well.

[mgravell]

At the moment I think this is "undefined". I agree it is something that should be handled better. Let me refamiliarize myself with that area. I wonder also whether the new "streams" support might be useful for your scenario.

…

On Fri, 6 Jul 2018, 21:27 Eric Pauley, ***@***.***> wrote: Related clarification, when does SubscribeAsync complete, when the command has been sent or when the SUBSCRIBE acknowledgement is received? Using PubSub for key change notifications so I need to wait until SUBSCRIBE is ack'd before fetching initial key status. Alternatively, give an additional SUBSCRIBE callback, since the same change checking code would need to run on connection drop as well. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#872 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsFcKP-lLIIvw6mh-P2RB0lBmLgT7ks5uD8gqgaJpZM4U-gFp> .

[NickCraver]

This is improved since #1947 - the command returns once actually subscribed (unless FireAndForget) and should behave in the expected way now.