Skip to content

Latest commit

 

History

History
100 lines (71 loc) · 6.89 KB

faq.md

File metadata and controls

100 lines (71 loc) · 6.89 KB
Raw

Frequently Asked Questions

Is Azure SignalR Service ready for production use?

Yes if you are using ASP.NET Core SignalR with Azure SignalR Service. The generally-available announcement is at here.

The support of ASP.NET SignalR is still in public preview.

Client connection is closed with error message "No server available". What does that mean?

This error occurs only when clients are sending messages to SignalR Service.

If you don't have any application server and only use SignalR Service's REST APIs, this is by design. In serverless architecture, client connections are in LISTEN mode and should not send any messages to SignalR Service. Read more about REST API in SignalR Service.

If you have application servers, this means there is no application server connected with your SignalR Service instance. Possible root causes are:

  • None of your application servers are connected to SignalR Service. Check application server logs to see whether there are connection errors. This should be very rare when you have multiple application servers for high availability.
  • There are some connectivity issues inside SignalR Service instances. It should be transient and recovered automatically within a couple of minutes. If it lasts for over an hour, please open an issue in GitHub or create an Azure support request. Then we can work with you to troubleshoot.

When there are multiple application servers, are messages from clients sent to all of them or just one of them?

It is one-to-one mapped between clients and application servers (server connections accurately). So messages from one client will only be sent to the same one application server.

The mapping between a client and an application server is valid in SignalR Service until the client or the application server disconnects.

If one of my application servers is down, will SignalR Service know about it? Will clients be notified too?

Yes.

SignalR Service monitors heartbeats from application servers. If there is no heartbeat for some time, the application server will be regarded as offline. All client connections which are served by this application server will be disconnected too.

Why is exception thrown from my custom IUserIdProvider when switching from ASP.NET Core SignalR to Azure SignalR Service SDK?

Parameter HubConnectionContext context is different in ASP.NET Core SignalR and Azure SignalR Service SDK when IUserIdProvider is called.

In ASP.NET Core SignalR, HubConnectionContext context is the context from the physical client connection and have valid values for all properties.

In Azure SignalR Service SDK, HubConnectionContext context is a logical client connection context. The physical client connection is connected to SignalR Service instance. So only limited properties are provided. For now, only HubConnectionContext.GetHttpContext() and HubConnectionContext.User is available for access. You can find the source code at here.

Can I configure available transports at server side in Azure SignalR Service like ASP.NET Core SignalR? Say WebSocket transport is disabled.

No.

Azure SignalR Service provides all 3 transports by default and you can't configure it. As a matter of fact, you don't have to worry about transports because clients are all connected to Azure SignalR Service and service will handle connection management.

But you can still configure allowed transports at client side as documented here.

What is the meaning of metrics like message count or connection count showed in Azure portal? Which kind of aggregation type should I choose?

You can find the details about how do we calculate these metrics here.

In the overview blade of Azure SignalR Service resources, we have already chosen the approperate aggregation type for you. And if you go to the Metrics blade, you can take the aggregation type here as a reference.

What is the meaning of service mode Default/Serverless/Classic? How can I choose?

Modes:

  • Default mode requires hub server. When there is no server connection available for the hub, the client tries to connect to this hub fails.

  • Serverless mode does NOT allow any server connection, i.e. it will reject all server connections, all clients must in serverless mode.

  • Classic mode is a mixed status. When a hub has server connection, the new client will be routed to hub server, if not, client will enter serverless mode.

    This may cause some problem, for example, all of server connections are lost for a moment, some clients will enter serverless mode, instead of route to hub server.

Choosing:

  1. No hub server, choose Serverless.
  2. All of hubs have hub servers, choose Default.
  3. Some of hubs have hub servers, others not, choose Classic, but this may cause some problem, the better way is create two instances, one is Serverless, another is Classic.