Charts not rendering in Blazor Server using Azure SignalR service

Question

Hi There.I've seen this topic discussed on one or two threads in the forum, but this hasn't really been addressed so opening a new thread.  In our app (which is a multitenant app which requires scale, hence using the SignalR managed service).  The app is hosted on Azure in App Services.  In my initial troubleshooting I suspect the issue is the message size supported in the SignalR service.  If you just use SignalR Core, and set the message size to the large number that was recommended in previous threads in this topic, the chart does render, but in a production environment that requires scale, this won't suffice.  Switching to Azure SignalR causes the client to disconnect from the circuit and reconnect, without the  chart actually loading.  If you set the signalR service logging mode to debug, you can see the messages received back from the circuit being cut up into multiple messages, and I think it actually just cuts off because there's too many messages.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 4096 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 4056, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 4136 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 40, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 4056 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 4096 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 4056, EndOfMessage: False.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 40, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 8152 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 4056, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 8192 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 40, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 12248 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 4056, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 12288 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 40, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 16344 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 4056, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 16384 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 40, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 20440 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 4056, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 20480 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 40, EndOfMessage: False.Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 24536 bytes from service 2a6f3054-7cec-4cf4-8f87-23ebf3fb4429.Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 41, EndOfMessage: True.There isn't any sort of exception that happens in the circuit, so this is pretty much impossible to troubleshoot.  It's also not possible to change the max message size in the Azure SignalR SDK to work around this problem, so I am at a bit of a loss here.  Syncfusion team, could you do a test using the azure signalR service with Blazor Server and see if you can reproduce it?  Is there something you can do on your end to reduce the heavy load of the charts?  should I enable canvas mode?

Durga Gopalakrishnan · Accepted Answer

Hi Travis,

Thanks for an update. We also suggest you specify SignalR maximum message size as 64KB as a minimum size in Startup.cs file to render the chart in azure hosted blazor application. This will resolve the reported console error. 





Startup.csservices.AddSignalR(e=> {      e.MaximumReceiveMessageSize = 63356; }).AddAzureSignalR();
Please revert us if you have any concerns.

Regards,
Durga G

HappyCamper · Answer

I actually found the point where it disconnects where it tries to render the chart:

Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 100, EndOfMessage: True.

Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 9733 bytes from service 080dc892-3dd3-417e-9b8d-444b01473b56.

Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Received message from application. Payload size: 76.

Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 100 bytes from service 080dc892-3dd3-417e-9b8d-444b01473b56.

Microsoft.Azure.SignalR.ServiceConnection: Debug: Waiting for the application to end.

Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Received message from application. Payload size: 38.

Microsoft.Azure.SignalR.ServiceConnection: Debug: Sending close connection message to the service for 8tDp1gJjZ3yhIaIVEoRU6w37a6b4c71.

Microsoft.Azure.SignalR.ServiceConnection: Debug: Connection 8tDp1gJjZ3yhIaIVEoRU6w37a6b4c71 ended.

Microsoft.Azure.SignalR.Connections.Client.Internal.WebSocketsTransport: Debug: Message received. Type: Binary, size: 38, EndOfMessage: True.

Microsoft.Azure.SignalR.ServiceConnection: Debug: Received 38 bytes from service 080dc892-3dd3-417e-9b8d-444b01473b56.

It seems that the circuit just gives up and terminates the connection, which causes the application circuit reconnect.

Durga Gopalakrishnan · Answer

Hi HappyCamper,

Greetings from Syncfusion.

We have ensured your reported scenario with provided error. We suggest you include the below code snippet in Startup.cs file to resolve the reported issue. 









services.AddSignalR().AddAzureSignalR(options =>              
{​​​​​​​                  
         options.ServerStickyMode = Microsoft.Azure.SignalR.ServerStickyMode.Required;              
}​​​​​​​);   
Please revert us if you have any concerns.

Regards,
Durga G

HappyCamper · Answer

Hi There,Server sticky mode has already been set as per recommendation before this issue arose. I confirmed that server sticky mode is in fact set as required.  However, issue persists.  Please advise on next troubleshooting steps.

Durga Gopalakrishnan · Answer

Hi HappyCamper,

We are analyzing your reported scenario. We will check this and update the details within two business days(25th February 2021). We appreciate your patience until then.

Regards,
Durga G

Travis · Answer

I know it's not in AddAzureSignalR, because there is no message size limit in Azure SignalR, but have you tried using the AddSignalR to set this value for Syncfusion while actually adding your connection string and sticky mode in the AddAzureSignalR.

services.AddSignalR(e => {e.MaximumReceiveMessageSize = 102400000; });

to the ConfigureServices in startup.cs?

I use the Azure App Service settings to set my Azure SignalR connection string and sticky mode and had to add the above line to the startup.cs to get charts to work. It still connects to the Azure SignalR service.

HappyCamper · Answer

Hi Travis,

Thanks for an update. We also suggest you specify SignalR maximum message size as 64KB as a minimum size in Startup.cs file to render the chart in azure hosted blazor application. This will resolve the reported console error. 





Startup.csservices.AddSignalR(e=> {      e.MaximumReceiveMessageSize = 63356; }).AddAzureSignalR();
Please revert us if you have any concerns.

Regards,
Durga GThanks Durga,This seems to have resolved the issue.  Ask:  Could you please update the docs to reflect this configuration, or add reference links in related documentation to make it obvious that this is required for the charts to render?

Durga Gopalakrishnan · Answer

Hi HappyCamper,

Most welcome. We have documented SignalR message size increase in blazor UG. We will include the changes for azure hosted application also in our upcoming weekly patch release which is scheduled to be rolled out on 2nd March 2021. We will let you know once it will be refreshed in online. 

UG Link : https://blazor.syncfusion.com/documentation/chart/getting-started/#add-syncfusionblazor-service-in-startupcs

Please revert us if you have any concerns.

Regards,
Durga G

Durga Gopalakrishnan · Answer

Hi HappyCamper,

Thanks for being patience. 

We have completed the reported changes and refreshed in live site. Please find the documentation link below.  

https://blazor.syncfusion.com/documentation/chart/getting-started/#add-syncfusionblazor-service-in-startupcs

Kindly revert us if you have any concerns. 

Regards,Durga G