Azure Service Bus topic subscription per web server

Question

I'm working to integrate a SignalR experience into an Azure infrastructure.

Basically, users take some action on the website that will trigger a function call on the web server (via SignalR). Processing that request can take time and users might send dozens or hundreds of those in a single click. I'm creating a Service Bus queue to send those tasks to a WebJob/Worker to process them and once they are ready they will send it back in another queue (response queue).

That said, to provide an awesome user experience, if the users are still on the same page as before and if the processing is ready I want it to update it for them real-time as those tasks are completed. That should be trivial if users were pinned to a single front-end box (due to SignalR WebSocket connection), but they are not, so a different front-end might need to process that response message and call the browser via SignalR.

When I post the message in the first queue, I'm including the SignalR ConnectionId. When the response is done, that ConnectionId is included with the response message, which gives me the chance to call.

HubContext.Clients.Client(connectionId).AddItemsResult(response);

My question is about Service Bus Topics -- or another solution I'm not fully understanding. I need each WebServer to be notified of each response processed since I can't figure out which webserver will actually call SignalR to the client.

1) Is Service Bus Topics the right way to do it?

2) It seems strange that I need to create N subscriptions (one for each web server) dynamically. What happens if a server dies and never comes back? I have a subscription that has no subscribers anymore?

Basically, I just want to create a simple publisher-subscriber pattern where I can have N dynamic subscribers (listeners) as they come online.

I might be missing something here, but I would think you'd want to pass the UserId instead of the connectionId, and then track the set of connectionId's per user in the hub OnConnected/OnDisconnected/OnReconnected events. Then, if you configure SignalR in your startup to use something to scaleout (e.g. Redis or Service Bus). Now when your hub receives the message, you find the set of connectionId's fort the associated user, and fire of the message to them. — Brendan Green

Chris Pietschmann Chris Pietschmann · Accepted Answer · 2018-06-26T20:47:55

You'll need to implement some kind of State Store that is updated when the processing is completed for each of the users requests. Then have the client periodically poll to get the latest status of that State Store for that uses requests. Also, you'll want to maintain that State Store, so the user can tell if their request has finished processing across multiple user / client sessions. The Scheduler Agent Supervisor messaging design pattern should help you implement what you are looking to build.

Here's a great explanation of the Scheduler Agent Supervisor messaging design pattern:

Scheduler Agent Supervisor pattern

Azure Service Bus topic subscription per web server

1 Answers