1

I'm using SignalR 1.0.4 and have a hub that returns a ChannelReader created from an observable by an extension.

A typescript client (also 1.0.4) is forced to connect using websockets only, and streams data from this channel fine.

Now I'm testing scale out using 2 instances of the hub, both using the same Redis connection. I'm emitting values from the channel's observable on both instances but the client only appears to be receiving data from the instance it is connected to. My conclusion is that the channel reader data is not broadcast to other channels via Redis.

I've tried to replicate this using the SignalRSamples by replicating the project and giving the copy different host IPs to emulate 2 load-balanced instances. I add the same Redis connection to both projects and start both up.

Regular websocket connections via the hubs.html have no problem broadcasting data across instances. The streaming.html doesn't replicate data for observable or channel reader.

Are channel readers meant to be used in this way, i.e. can they scale out?

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
Mark
  • 1,059
  • 13
  • 25

1 Answers1

0

ChannelReaders are meant to stream data down to the caller of the method. They don't participate in scale-out at all. Consider them the same as standard return values, SignalR just supports enumerating items off them over time. The programming model is very similar to how iterators work in C# (methods that use the yield keyword). If you want to broadcast messages to other clients, you should just use the Clients property on the Hub base class and send messages to those clients.

Andrew Stanton-Nurse
  • 6,274
  • 1
  • 28
  • 20
  • In my use case, each load-balanced, scaled-out instance registers to the same Azure Service Bus topic subscription in a competing-consumer fashion, meaning only one instance receives an event. This event should propagate to all SignalR-connected parties. I thought I could just push this event onto one of the source observables used in a channel reader and let SignalR do the rest. Admittedly I was wondering how SignalR would do this. I think it should be fairly easy to refactor. Do you think a documentation update might be required here? – Mark Oct 29 '18 at 22:33