AddAzureSignalR and ServerStickyMode with two Azure SignalR resources and two Web App services

Question

Currently we have a configuration of two Azure SignalR resources, primary and secondary endpoints and two web app services that are configured with the two signalr resources (below code). My question is why the documentation contradictory?, we have documentation that says its required and other documentation that says it isn't, however when disabled it does not work all the time, just intermittently, so it really is required. Would the amount of instances (sku units) also affect ServerStickyMode?

*Not Required?

https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-7.0#azure-signalr-service

"The only circumstances in which sticky sessions are not required are:"

1. When using the Azure SignalR Service.

"Sticky sessions, also known as client affinity, is not required, because clients are immediately redirected to the Azure SignalR Service when they connect."

*Required?

https://devblogs.microsoft.com/dotnet/whats-new-in-azure-signalr-1-1-0-preview-1/#:~:text=Also%20when%20sticky%20mode%20is%20enabled%2C%20service%20won%E2%80%99t,only%20enable%20it%20when%20there%20is%20a%20need.

"The typical connection flow when using SignalR service is that client first negotiates with app server to get the url of SignalR service, then service routes client to app server.

When you have multiple app servers, there is no guarantee that two servers (the one who does negotiation and the one who gets the hub invocation) will be the same one.

We hear a lot of customers asking about whether it’s possible to make the two servers the same one so they can share some states between negotiation and hub invocation. In this release we have added a new “server sticky mode” to support this scenario.

To enable this, you just need to set ServerStickyMode to Required in AddAzureSignalR():"

Any help would be appreciated.

Answer 1

To benefit the community, posting our offline discussion points:

With the workflow you had described, typically, there should not be any issue, and stickyservermode should not be needed, nonetheless for a deeper investigation we may have to dig/review logs from your side.

 

For the serverless part, our serverless mode supports both HTTP REST and WebSocket connection, so the performance should be good too.

 

One way to verify if the endpoints are configured corrected is to add logger using WithLoggerFactory and the logs will show what endpoints it is trying to connect to and if it is successfully connected to the endpoints:

 

Just to highlight, the sticky session is not needed when you’re using Azure SignalR Service.

Please note sticky session is different than “server sticky mode”, which is a unique feature in SignalR service to guarantee client first negotiates and then connects to the same application server (a typical use case is in blazor server).

 

You could  use ApplicationName (https://github.com/Azure/azure-signalr/blob/dev/docs/run-asp-net-core.md#applicationname) to isolate the two app services, otherwise you’ may get unexpected result (clients will be routed randomly between two apps).

Answer 2

@Carlante ,

Sticky sessions should not be required when using the Azure SignalR Service. Any one of the three listed "circumstances" (in the doc), is enough to mean sticky sessions are not needed. It should not matter how many instances there are.

 

You may checkout this similar’ discussion thread
Azure App service sticky session · Issue #1302 · Azure/azure-signalr · GitHub
(The issue was eventually related to some other part of the app that relied on sticky sessions.)

  

A lack of sticky sessions does mean that a single browser/client could be connected to a Hub running on a different instance than the ASP.NET Core app that handles the browser's/client's other, non-SignalR-related requests. This typically isn't a problem, but this can lead to some issues in app logic unrelated to SignalR itself.

You may rely on the Azure doc ( that you referenced). Thanks for sharing your feedback on the blog (published in 2019). I’ll internally relay the feedback to the blog author.