Open monderino opened 3 years ago
@monderino Quickly checked our service log with some information from your traces and it looks the client are closed by the app server during incident time. Suggest you can open server logs to have a check if why server did that.
Guides about enable server logs. https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-howto-troubleshoot-method#enable-server-side-logging-for-aspnet-core-signalr
Hi @JialinXin,
thank you for the tipp. I actually don't see any significant log.
The Logs in the signalR service tells me: "Connection ended. Reason: Application server closed the connection." or "Connection ended. Reason: "
and the logs in my application only say: Request starting HTTP/1.1 GET http://xxx.hellohq.io/images/error/connection_lost.svg - - The file "/images/error/connection_lost.svg" was not modified Request finished HTTP/1.1 GET http://xxx.hellohq.io/images/error/connection_lost.svg - - - 304 - image/svg+xml 0.2199ms Request starting HTTP/1.1 POST http://xxx.hellohq.io/_blazor/negotiate?negotiateVersion=1 text/plain;charset=UTF-8 0
no further error or anything.
@monderino From your original logs, there're 2 errors worth taking a look. It seems your client code has something wrong and you can check the websocket.onerror(evt)
logs. Check this with some further guides.
blazor.server.js:1 [2021-09-28T09:52:27.231Z] Error: Connection disconnected with error 'Error: WebSocket closed with status code: 1006 ().'.
And this one seems that the process is stuck in some place and leads to timeout. You may either improve the TimeoutInterval
a little bit or find out the stuck place.
blazor.server.js:1 [2021-09-28T09:55:48.795Z] Error: Connection disconnected with error 'Error: Server timeout elapsed without receiving a message from the server.'.
hi @JialinXin,
you mean I should increase the ClientTimeoutInterval?
I'm not sure how I can use the websocket.onerror(evt), because I use the blazor.server.js which does all the magic for me.
<script src="_framework/blazor.server.js" autostart="false"></script>
document.addEventListener("DOMContentLoaded", function() {
Blazor.start({
logLevel: 1, // LogLevel.Debug
configureSignalR: builder => builder.configureLogging("debug"), // LogLevel.Debug
reconnectionOptions: { // Retry 5 min
maxRetries: 300,
retryIntervalMilliseconds: 1000,
}
});
});
Increase ClientTimeoutInterval may help mitigate second issue but I'm wondering it may be related to issue1 and something not working properly in your client code. You issue is likely to be similar with https://github.com/dotnet/aspnetcore/issues/21881
Can you repro the issue under local SignalR? Remove the dependency with Azure SignalR service to check if it repros. And if so, suggest to open an issue to server-side blazor team who are expects on this.
Or would you provide a simplified version of repro code to let me investigate this? I'm not able to provide much help under current information. Let me know how you'd like to proceed.
Thanks for the help. Currently I didn't find a way to reproduce it locally. I let you know when I find a way.
We have a Blazor Server App which is connected to the Azure SignalR Service. More or less randomly we get a disconnect and our clients need to reload to establish the connection again. I added logs to the client and server side to find the reason, but the logs of the SignalR Service tells me only 'Connection ended. Reason: '. Have anyone an idea when this can happen?
All my configurations should avoid that the server close the connection. It should only happen when the client is really long offline. Server Config:
I use dotnet core 5.0 and Microsoft.AspNetCore.SignalR.Client Version=5.0.10 Microsoft.Azure.SignalR Version=1.11.0
The app is running in a kubernetes cluster on the mcr.microsoft.com/dotnet/sdk:5.0 image.
When a disconnect happen, the client show the following logs:
And the SignalR tells me:
Has anyone an hint for me, how I get detailed logs about the connection end or if maybe something wrong in my configuration. My goal is the reduce the disconnection as much as possible.
Thanks for your help.