SignalR sometime throws exception (approximately 4 exceptions/week) «Failed connection handshake».
I think reason could be unstable internet connection on client but I’m not sure (other reason could be wrong configuration or implementation). Has anyone the same problem? And should I solve it when most of the time it is ok?
It is MVC .Net Core app.
Here is log:
{"EventId":{"Id":5,"Name":"HandshakeFailed"},"SourceContext":"Microsoft.AspNetCore.SignalR.HubConnectionContext","TransportConnectionId":"rC64r0HCfzSQCqE7OB5h-A","RequestId":"0HLNJ4TCNIKN8:00000002","RequestPath":"/hub/status","CorrelationId":null,"ConnectionId":"0HLNJ4TCNIKN8"}
I am trying to use SignalR in my .NET CORE 3.1 webapi(server) and angular 10(client) project. API (https://localhost:44305/api) and client angular (https://localhost:44305/user/signup) project shares same domain. This is how I have setup signalR in the server side:
-
I have created Hub class
using Microsoft.AspNetCore.SignalR; namespace Web.Hubs { public class ResponseHub : Hub { } }
-
In Startup.cs class, added services.AddSignalR() in the ConfigureService method. And Enabled CORS like :
services.AddCors(options =>{ options.AddPolicy(MyAllowSpecificOrigins, builder => { builder .WithOrigins(Configuration.GetValue<string>("https://localhost:44305")) .AllowAnyHeader() .AllowAnyMethod() .AllowCredentials(); }); });
And added following lines in configure method :
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller}/{action=Index}/{id?}");
endpoints.MapHub<ResponseHub>("/userdetails/response");
});
In the client side,
-
I have installed «@microsoft/signalr»: «^3.1.9» package in the angular project.
-
created service for the signalR like :
import { Signalrresponse } from "./signalrresponse"; import { Router } from "@angular/router"; import * as signalR from '@microsoft/signalr'; @Injectable({ providedIn: 'root' }) export class SignalRService{ constructor(private router: Router){} public data : Signalrresponse; private hubConnection: signalR.HubConnection public startConnection = () =>{ this.hubConnection = new signalR.HubConnectionBuilder() .withUrl("https://localhost:44305/api/userdetails/response") .build(); this.hubConnection .start() .then(() => console.log("Connection Started")) .catch(err => console.log('Error while starting connection: ' + err)) } public addTransferChartDataListener = () =>{ this.hubConnection.on('changestatus',(data)=>{ console.log("Received data"); this.data = data; }) } }
I am getting error while trying to establish connection from the client side. Error message : Error: Failed to start the connection: Error: None of the transports supported by the client are supported by the server.
Please help me in fixing this.
Thanks.
I am trying to use SignalR in my .NET CORE 3.1 webapi(server) and angular 10(client) project. API (https://localhost:44305/api) and client angular (https://localhost:44305/user/signup) project shares same domain. This is how I have setup signalR in the server side:
-
I have created Hub class
using Microsoft.AspNetCore.SignalR; namespace Web.Hubs { public class ResponseHub : Hub { } }
-
In Startup.cs class, added services.AddSignalR() in the ConfigureService method. And Enabled CORS like :
services.AddCors(options =>{ options.AddPolicy(MyAllowSpecificOrigins, builder => { builder .WithOrigins(Configuration.GetValue<string>("https://localhost:44305")) .AllowAnyHeader() .AllowAnyMethod() .AllowCredentials(); }); });
And added following lines in configure method :
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller}/{action=Index}/{id?}");
endpoints.MapHub<ResponseHub>("/userdetails/response");
});
In the client side,
-
I have installed «@microsoft/signalr»: «^3.1.9» package in the angular project.
-
created service for the signalR like :
import { Signalrresponse } from "./signalrresponse"; import { Router } from "@angular/router"; import * as signalR from '@microsoft/signalr'; @Injectable({ providedIn: 'root' }) export class SignalRService{ constructor(private router: Router){} public data : Signalrresponse; private hubConnection: signalR.HubConnection public startConnection = () =>{ this.hubConnection = new signalR.HubConnectionBuilder() .withUrl("https://localhost:44305/api/userdetails/response") .build(); this.hubConnection .start() .then(() => console.log("Connection Started")) .catch(err => console.log('Error while starting connection: ' + err)) } public addTransferChartDataListener = () =>{ this.hubConnection.on('changestatus',(data)=>{ console.log("Received data"); this.data = data; }) } }
I am getting error while trying to establish connection from the client side. Error message : Error: Failed to start the connection: Error: None of the transports supported by the client are supported by the server.
Please help me in fixing this.
Thanks.
У меня есть простой проект клиента чата, работающий с использованием SignalR и MVC, который почти идентичен ASP.Net один (Я просто экспериментирую — код клиента идентичен). Я подключил следующее, чтобы наблюдать за происходящим:
$.connection.hub.stateChanged(function(state){console.log(state)});
Соединения работают нормально, но я заметил, что если я закрываю IIS Express и смотрю консоль в Chrome, я вижу это:
//As you would expect the state goes from connected to connecting
Object {oldState: 1, newState: 2}
//Then it times out after about 30 secs and throws this awesomeness at the console
WebSocket connection to 'ws://localhost:61623/signalr?transport=webSockets&connectionToken=VDF640emz7PFMToC6vxle_5-7QS5dZMszV4SPbQO7EFEmSSsITnwKsZreqfl4MGq8TXitG2xB5F-2ZdHp-2t3shPzN2hemTY1ZmEWlB8NOn5orUVexaSoARk9XjEO5B00&connectionData=%5B%7B%22name%22%3A%22chathub%22%7D%5D&messageId=B%2C7%7CL%2C0%7CM%2C0%7CN%2C0&tid=0' failed: WebSocket is closed before the connection is established. jquery.signalR-1.0.1.js:1117
//Reconnecting to Disconnecting - so why the error above?
Object {oldState: 2, newState: 4}
//Then radio silence if I start IIS again...
2 вопросы:
Как избежать ошибки при неудачной попытке повторного подключения?
Почему SignalR не пытается подключиться к IIS? У меня сложилось впечатление, что в этом суть технологии…
РЕДАКТИРОВАТЬ: то же самое происходит и в FireFox
title | description | author | ms.service | ms.topic | ms.date | ms.author | ms.openlocfilehash | ms.sourcegitcommit | ms.translationtype | ms.contentlocale | ms.lasthandoff | ms.locfileid |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Руководство по устранению неполадок для Службы Azure SignalR |
Сведения об устранении распространенных неполадок |
yjin81 |
signalr |
conceptual |
11/06/2020 |
yajin1 |
e26def56fbd03626c3efc660db57012ee1b767ea |
ed7376d919a66edcba3566efdee4bc3351c57eda |
MT |
ru-RU |
03/24/2021 |
105048210 |
Руководство по устранению неполадок службы Azure SignalR
Это руководство содержит полезные рекомендации по устранению неполадок на основе распространенных проблем, которые пользователи составили и устраняют за последние годы.
Слишком длинный маркер доступа
Возможные ошибки
- На стороне клиента
ERR_CONNECTION_
- 414 — слишком длинный универсальный код ресурса (URI)
- 413 (слишком большой объем полезных данных)
- Длина маркера доступа не должна превышать 4 КБ. 413 — размер запрашиваемой сущности слишком большой
Первопричина
Для HTTP/2 Максимальная длина для одного заголовка равна 4 КБ, поэтому при использовании браузера для доступа к службе Azure произойдет ошибка ERR_CONNECTION_
для этого ограничения.
Для клиентов HTTP/1.1 или C# максимальная длина URI составляет 12 КБ, максимальная длина заголовка — 16 КБ.
При использовании пакета SDK версии 1.0.6 или более поздней /negotiate
выдается исключение, 413 Payload Too Large
Если созданный маркер доступа больше 4 КБ.
Решение
По умолчанию утверждения из context.User.Claims
включаются при создании маркера доступа JWT для АСРС(Zure игнал R s ервице), чтобы утверждения сохранялись и можно было передавать из АСРС в, Hub
когда клиент подключается к Hub
.
В некоторых случаях context.User.Claims
используется для хранения большого количества сведений для сервера приложений, большинство из которых не используются, Hub
а другими компонентами.
Созданный маркер доступа передается через сеть, а для соединений WebSocket и SSE маркеры доступа передаются через строки запроса. Поэтому мы рекомендуем передавать на сервер приложений только необходимые утверждения от клиента через АСРС , когда это необходимо.
ClaimsProvider
Для настройки утверждений, передаваемых в АСРС внутри маркера доступа, можно настроить.
Для ASP.NET Core:
services.AddSignalR() .AddAzureSignalR(options => { // pick up necessary claims options.ClaimsProvider = context => context.User.Claims.Where(...); });
Для ASP.NET:
services.MapAzureSignalR(GetType().FullName, options => { // pick up necessary claims options.ClaimsProvider = context.Authentication?.User.Claims.Where(...); });
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Требуется TLS 1,2
Возможные ошибки
- ASP.NET об ошибке «сервер недоступен» #279
- ASP.NET «Подключение неактивно, данные не могут быть отправлены в службу». #324 об ошибке
- «Произошла ошибка при выполнении HTTP-запроса к https:// . Эта ошибка может быть вызвана тем, что сертификат сервера неправильно настроен с HTTP.SYS в случае HTTPS. Эта ошибка также может быть вызвана несоответствием привязки безопасности между клиентом и сервером. «
Первопричина
Служба Azure поддерживает только TLS 1.2 в целях безопасности. В .NET Framework возможно, что TLS 1.2 не является протоколом по умолчанию. В результате невозможно успешно установить подключения сервера к АСРС.
Руководство по устранению неполадок
-
Если эту ошибку можно воспроизвести локально, снимите флажок только мой код и вызывайте все исключения CLR и отлаживать сервер приложений локально, чтобы увидеть, что вызывает исключение.
-
Снять только мой код
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/uncheck-just-my-code.png» alt-text=»Снять Только мой код»:::
-
Выдавать исключения CLR
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/throw-clr-exceptions.png» alt-text=»Выдавать исключения CLR»:::
-
См. исключения, возникающие при отладке кода на стороне сервера приложений:
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/tls-throws.png» alt-text=»Исключение»:::
-
-
Для ASP.NET можно также добавить следующий код в,
Startup.cs
чтобы включить подробную трассировку и просмотреть ошибки из журнала.app.MapAzureSignalR(this.GetType().FullName); // Make sure this switch is called after MapAzureSignalR GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;
Решение
Добавьте в запуск следующий код:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
400 для клиентских запросов возвращен неверный запрос
Первопричина
Проверьте, содержит ли ваш запрос клиента несколько hub
строк запроса. hub
сохраненный параметр запроса, и 400 выдаст исключение, если служба обнаружит hub
в запросе более одного.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
401 Unauthorized returned for client requests (Возврат ошибки с кодом «401 — не санкционировано» для клиентских запросов)
Первопричина
В настоящее время время жизни маркера JWT по умолчанию — 1 час.
Для ASP.NET Core SignalR, когда он использует тип транспорта WebSocket, это нормально.
Для другого типа транспорта ASP.NET Core SignalR, SSE и длительного опроса, это означает, что по умолчанию подключение может храниться не более 1 часа.
Для ASP.NET SignalR клиент отправляет /ping
службе запрос на KeepAlive время от времени, когда /ping
происходит сбой, клиент прерывает подключение и никогда не переключается. Это означает, что для ASP.NET SignalR время существования токена по умолчанию делает подключение продолжительностью не более 1 часа для всех типов транспорта.
Решение
В целях безопасности не рекомендуется расширять TTL. Мы рекомендуем добавить логику повторного подключения из клиента, чтобы перезапустить подключение при возникновении такой ошибки 401. Когда клиент перезапускает подключение, он будет согласовываться с сервером приложений для повторного получения маркера JWT и получения обновленного маркера.
Установите здесь , чтобы перезапустить клиентские подключения.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
404 returned for client requests (Возврат ошибки с кодом 404 для клиентских запросов)
Для постоянного подключения SignalR сначала /negotiate
необходимо установить службу Azure SignalR, а затем — реальное подключение к службе Azure SignalR.
Руководство по устранению неполадок
- Чтобы Просмотреть исходящие запросы на получение запроса от клиента к службе, необходимо выполнить следующие требования.
- Проверьте URL-адрес запроса при возникновении ошибки 404. Если URL-адрес предназначен для веб-приложения и аналогичен
{your_web_app}/hubs/{hubName}
, проверьте, имеет ли клиентSkipNegotiation
true
. При использовании Azure SignalR клиент получает URL-адрес перенаправления при первом согласовании с сервером приложений. Клиент не должен пропускать согласование при использовании Azure SignalR. - Еще один 404 может произойти, когда запрос на подключение обрабатывается более 5 секунд после
/negotiate
вызова. Проверьте метку времени запроса клиента и откройте сообщение о том, что в случае, если запрос к службе имеет слишком много откликов.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
404 возвращается для запроса на повторное подключение SignalR ASP.NET
Для ASP.NET SignalR при удалении клиентского соединенияон повторно подключается в connectionId
течение трех раз, прежде чем остановить подключение. /reconnect
может помочь, если подключение отбрасывается из-за временных неполадок сети, которые /reconnect
могут успешно восстановить постоянное подключение. В других случаях, например, подключение клиента отбрасывается из-за разрыва соединения с перенаправленным сервером, или служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа или развертывание, поэтому соединение больше не существует, поэтому /reconnect
возвращается 404
. Это ожидаемое поведение в /reconnect
и после трех раз, когда повторная попытка подключения прекращается. Мы рекомендуем подать логику перезапуска подключения при остановке соединения.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
429 (слишком много запросов) возвращено для клиентских запросов
Есть два способа.
Число одновременных подключений превышает предел
Для свободных экземпляров ограничение числа одновременных подключений равно 20 для стандартных экземпляров, ограничение числа одновременных подключений на единицу равно 1 K, что означает, что Unit100 допускает одновременные подключения 100-K.
Подключения включают как клиентские, так и серверные соединения. Проверьте , как подсчитываются подключения.
Слишком много запросов на согласование одновременно
Мы рекомендуем установить произвольную задержку перед повторной попыткой подключения, чтобы проверить примеры повторных попыток.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
500 ошибка при согласовании: служба Azure SignalR еще не подключена, повторите попытку позже.
Первопричина
Эта ошибка возникает при отсутствии подключения сервера к службе SignalR Azure.
Руководство по устранению неполадок
Включите трассировку на стороне сервера, чтобы узнать сведения об ошибке, когда сервер пытается подключиться к службе Azure SignalR.
Включение ведения журнала на стороне сервера для ASP.NET Core SignalR
Ведение журнала на стороне сервера для ASP.NET Core SignalR интегрируется с ILogger
журналом на основе ASP.NET Core Framework. Вы можете включить ведение журнала на стороне сервера с помощью ConfigureLogging
, выбрав пример использования следующим образом:
.ConfigureLogging((hostingContext, logging) => { logging.AddConsole(); logging.AddDebug(); })
Категории средств ведения журнала для Azure SignalR всегда начинаются с Microsoft.Azure.SignalR
. Чтобы включить подробные журналы из Azure SignalR, настройте предыдущие префиксы для Debug
уровня appsettings.jsв файле, как показано ниже:
{ "Logging": { "LogLevel": { ... "Microsoft.Azure.SignalR": "Debug", ... } } }
Включение трассировки на стороне сервера для ASP.NET SignalR
При использовании пакета SDK версии >= 1.0.0
можно включить трассировку, добавив следующую команду в web.config
: (Details).
<system.diagnostics> <sources> <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch"> <listeners> <add name="ASRS" /> </listeners> </source> </sources> <!-- Sets the trace verbosity level --> <switches> <add name="SignalRSwitch" value="Information" /> </switches> <!-- Specifies the trace writer for output --> <sharedListeners> <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" /> </sharedListeners> <trace autoflush="true" /> </system.diagnostics>
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Разрывы соединения с клиентом
Когда клиент подключается к Azure SignalR, постоянное подключение между клиентом и Azure SignalR иногда может быть удалено по разным причинам. В этом разделе описываются некоторые возможности, вызывающие такое удаление подключения, и приводятся некоторые рекомендации по определению основной причины.
Возможные ошибки со стороны клиента
The remote party closed the WebSocket connection without completing the close handshake
Service timeout. 30.00ms elapsed without receiving a message from service.
{"type":7,"error":"Connection closed with an error."}
{"type":7,"error":"Internal server error."}
Первопричина
Клиентские подключения могут удаляться при различных обстоятельствах:
- При
Hub
вырождении исключений с входящим запросом. - Когда соединение с сервером, на которое направляется клиент, удаляется, см. ниже в разделе с подробными сведениями о падении соединения с сервером.
- При возникновении проблемы с сетевым подключением между клиентом и службой SignalR.
- Когда служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа, развертывание и т. д.
Руководство по устранению неполадок
- Откройте журнал на стороне сервера приложений, чтобы проверить, не произошло ли что-либо непредвиденное
- Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
- Создайте ошибку, предоставляющую время, и отправьте имя ресурса по адресу
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Подключение клиента постоянно увеличивается
Это может быть вызвано неправильным использованием клиентского соединения. Если кто-то забыл закрыть или ликвидировать клиент SignalR, соединение остается открытым.
Возможные ошибки в метриках SignalR, которые находятся в разделе «Мониторинг» портал Azure меню ресурсов
Клиентские подключения постоянно наиграют в течение длительного времени в метриках Azure SignalR.
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/client-connection-increasing-constantly.jpg» alt-text=»Подключение клиента постоянно растет»:::
Первопричина
Подключение клиента SignalR DisposeAsync
никогда не вызывается, подключение остается открытым.
Руководство по устранению неполадок
Проверьте, не закрывается ли клиент SignalR.
Решение
Убедитесь, что подключение закрыто. Вызов метода HubConnection.DisposeAsync()
останавливает подключение вручную после его использования.
Пример:
var connection = new HubConnectionBuilder() .WithUrl(...) .Build(); try { await connection.StartAsync(); // Do your stuff await connection.StopAsync(); } finally { await connection.DisposeAsync(); }
Распространенное неправильное использование подключения клиента
Пример функции Azure
Эта проблема часто возникает, когда кто-то устанавливает клиентское подключение SignalR в методе функции Azure вместо того, чтобы сделать его статическим членом класса функции. Вы можете ожидать, что установлено только одно клиентское подключение, но количество подключений клиентов постоянно увеличивается в метриках, которые находятся в разделе «Мониторинг» в портал Azure меню ресурсов. все эти подключения отменяются только после перезапуска функции Azure или службы Azure SignalR. Это связано с тем, что при каждом запросе функция Azure создает одно клиентское соединение, если подключение клиента в методе функции не будет прервано, клиент будет поддерживать подключения в службе Azure SignalR.
Решение
- Не забудьте закрыть клиентское подключение, если вы используете SignalR Clients в функции Azure или используете клиент SignalR в качестве одноэлементного.
- Вместо использования клиентов SignalR в функции Azure вы можете создавать клиенты SignalR в любом месте и использовать привязки функций Azure для службы Azure SignalR для согласования клиента с Azure SignalR. Кроме того, можно использовать привязку для отправки сообщений. Примеры для согласования клиентов и отправки сообщений можно найти здесь. Дополнительные сведения можно найти здесь.
- При использовании клиентов SignalR в функции Azure может быть улучшена архитектура вашего сценария. Проверьте, правильно ли разрабатывается бессерверная архитектура. Вы можете обращаться к бессерверным приложениям в режиме реального времени с привязками службы SignalR в функциях Azure.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Падения подключений к серверу
Когда сервер приложений запускается, в фоновом режиме пакет SDK для Azure начинает инициировать подключения к удаленному серверу Azure SignalR. Как описано в статье внутренние компоненты службы Azure SignalR, Azure SignalR направляет входящие клиентские трафик на эти подключения к серверу. После удаления соединения с сервером все клиентские подключения, которые он обслуживает, будут закрыты.
Поскольку подключения между сервером приложений и службой SignalR являются постоянными подключениями, они могут испытывать проблемы с сетевым подключением. В пакете SDK для сервера мы всегда повторно подключаем стратегию к подключениям к серверу. Рекомендуется также рекомендовать пользователям добавлять логику непрерывного повторного подключения к клиентам с произвольным временем задержки, чтобы избежать массовых одновременных запросов к серверу.
На регулярной основе для службы Azure SignalR предусмотрены новые версии версий, а иногда установка исправлений или обновления операционной системы для всего Azure, а также иногда прерывание от наших зависимых служб. Это может привести к кратковременному прерыванию работы службы, но при условии, что клиент на стороне клиента имеет механизм отключения и повторного подключения, такое влияние минимально, как и на стороне клиента, вызванного отключением и повторному подключению.
В этом разделе описаны несколько возможностей, ведущих к удалению подключения к серверу, и приводятся некоторые рекомендации по определению основной причины.
Возможные ошибки со стороны сервера
[Error]Connection "..." to the service was dropped
The remote party closed the WebSocket connection without completing the close handshake
Service timeout. 30.00ms elapsed without receiving a message from service.
Первопричина
Подключение к службе сервера закрыто АСРС(A Zure игнал****R s ервице).
Для времени ожидания проверки связи это может быть вызвано высокой нагрузкой ЦП или нехватка пула потоков на стороне сервера.
В ASP.NET SignalR была исправлена известная проблема в пакете SDK 1.6.0. Обновите пакет SDK до последней версии.
Нехватка ресурсов пула потоков
Если сервер не используется, это означает, что потоки не работают над обработкой сообщений. Все потоки не отвечают в определенном методе.
Обычно этот сценарий вызывается асинхронно для синхронизации или Task.Result
/ Task.Wait()
в асинхронных методах.
См. ASP.NET Core рекомендации по повышению производительности.
См. Дополнительные сведения о нехватке пула потоков.
Как определить нехватку пула потоков
Проверьте число потоков. Если в это время нет пиковых нагрузок, сделайте следующее:
-
Если вы используете службу приложений Azure, проверьте количество потоков в метриках. Проверьте
Max
агрегирование::::image type=»content» source=»media/signalr-howto-troubleshoot-guide/metrics-thread-count.png» alt-text=»Снимок экрана: панель «максимальное число потоков» в службе приложений Azure.»:::
-
Если вы используете платформа .NET Framework, вы можете найти метрики в системном мониторе на виртуальной машине сервера.
-
Если вы используете .NET Core в контейнере, см. раздел получение диагностических сведений в контейнерах.
Можно также использовать код для обнаружения недостаточности пула потоков:
public class ThreadPoolStarvationDetector : EventListener { private const int EventIdForThreadPoolWorkerThreadAdjustmentAdjustment = 55; private const uint ReasonForStarvation = 6; private readonly ILogger<ThreadPoolStarvationDetector> _logger; public ThreadPoolStarvationDetector(ILogger<ThreadPoolStarvationDetector> logger) { _logger = logger; } protected override void OnEventSourceCreated(EventSource eventSource) { if (eventSource.Name == "Microsoft-Windows-DotNETRuntime") { EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All); } } protected override void OnEventWritten(EventWrittenEventArgs eventData) { // See: https://docs.microsoft.com/en-us/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment && eventData.Payload[3] as uint? == ReasonForStarvation) { _logger.LogWarning("Thread pool starvation detected!"); } } }
Добавьте его в службу:
service.AddSingleton<ThreadPoolStarvationDetector>();
Затем проверьте журнал, когда соединение с сервером отключается по истечении времени ожидания проверки связи.
Как найти основную причину нехватка ресурсов пула потоков
Чтобы найти основную причину нехватка ресурсов пула потоков, выполните следующие действия.
- Выведите дамп памяти, а затем проанализируйте стек вызовов. Дополнительные сведения см. в разделе Получение и анализ дампов памяти.
- Используйте клрмд для дампа памяти при обнаружении нехватки ресурсов пула потоков. Затем зайдите в журнал стека вызовов.
Руководство по устранению неполадок
- Откройте журнал на стороне сервера приложений, чтобы проверить, не выполнялось ли что-либо непредвиденное.
- Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
- Создайте вопрос. Укажите интервал времени и отправьте имя ресурса по электронной почте.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Советы
- Как просмотреть исходящий запрос от клиента?
Возьмем ASP.NET Core один пример (ASP.NET похож):-
Из браузера:
Возьмем Chrome в качестве примера. можно использовать F12 , чтобы открыть окно консоли, и перейти на вкладку сеть . Возможно, потребуется обновить страницу с помощью клавиши F5 , чтобы захватить сеть с самого начала.
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/chrome-network.gif» alt-text=»Сеть представления Chrome»:::
-
Из клиента C#:
Вы можете просматривать локальные веб-трафик с помощью Fiddler. Трафик WebSocket поддерживается с момента Fiddler 4,5.
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network-inline.png» alt-text=»Fiddler просмотр сети» lightbox=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network.png»:::
-
-
Как перезапустить клиентское подключение?
Ниже приведены примеры кодов , содержащих перезапуск логики подключения с использованием всегда стратегии повторных попыток :
-
Клиент ASP.NET Core C#
-
ASP.NET Core клиент JavaScript
-
Клиент ASP.NET C#
-
Клиент ASP.NET JavaScript
-
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Дальнейшие действия
В этом руководство вы узнали, как решать распространенные проблемы. Вы также можете узнать больше об общих методах устранения неполадок.
[!div class=»nextstepaction»]
Устранение проблем с подключением и доставкой сообщений
Всем привет. Разрабатываю SPA приложение на ASP.NET Core Vue.js. Подключил SignalR. Все работает, как ожидалось. Но осталась одна проблема.
После входя в систему со спящего режима через определенное время соединение с SignalR перестает работать.
Ошибки:
Код
Error: Connection disconnected with error 'Error: Error occurred'. net::ERR_CONNECTION_RESET Error: Failed to complete negotiation with the server Error: Failed to start the connection Failed to load resource: net::ERR_NAME_NOT_RESOLVED Uncaught (in promise) Error at new e (vendors~main.js:7) at XMLHttpRequest.i.onerror
(Оффтоп) Но так же выдает ошибки и webpack (не связано с SignalR):
Код
Failed to load resource: net::ERR_NAME_NOT_RESOLVED Failed to load resource: net::ERR_ADDRESS_UNREACHABLE Failed to load resource: net::ERR_NETWORK_IO_SUSPENDED
Данные ошибки появляются только после входа в систему после спящего режима через определенное время.
Пытался соединяться после разрыва соединения:
Javascript | ||
|
Работает только в случае отсоединения по другим причинам. Но после спящего режима не работает, т.к. он не может соединиться.
Пытался подключаться вручную с помощью метода. Срабатывало.
В чем может быть проблема? Возможно ли настроить соединение работать более стабильно? Или дело не в этом?
Заранее благодарен.
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
Всем привет. Может быть я и задаю много вопросов. Пытаюсь подключиться к SignalR Hub с SPA-приложения.
this.hubConnection = new HubConnectionBuilder()
.withUrl('http://localhost:*****/testhub')
.configureLogging(LogLevel.Information)
.build()
Появляется ошибка: Error: Failed to complete negotiation with the server: SyntaxError: Unexpected token < in JSON at position 0
Пробовал так:
this.hubConnection = new HubConnectionBuilder()
.withUrl('http://localhost:*****/testhub', {
skipNegotiation: true,
transport: HttpTransportType.WebSockets
})
.configureLogging(LogLevel.Information)
.build()
Ошибка:
WebSocket connection to ‘ws://localhost:50523/testhub’ failed: Error during WebSocket handshake: Unexpected response code: 200
Использование веб-сокетов в Startup.cs я включил. Пробовал менять версию SignalR в клиентской части, ошибка не исчезает. В многостраничных приложениях все нормально.
В чем может быть проблема?
#asp.net-core #nginx #signalr
Вопрос:
У меня возникли проблемы с подключением к серверу SignalR. Моя первоначальная настройка на nginx была
location /notificationHub/ {
rewrite ^/notificationHub/?(.*) /notificationHub/$1 break;
proxy_pass http://api_beta_server;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
Ответ №1:
Из документации Microsoft ниже приведены минимальные необходимые параметры для включения WebSockets в Nginx
# add this at the top of ninx config
map $http_connection $connection_upgrade {
"~*Upgrade" $http_connection;
default keep-alive;
}
# Configure the SignalR Endpoint inside server setting
location /hubroute {
# App server url
proxy_pass http://localhost:5000;
# Configuration for WebSockets
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_cache off;
# WebSockets were implemented after http/1.0
proxy_http_version 1.1;
# Configuration for ServerSentEvents
proxy_buffering off;
# Configuration for LongPolling or if your KeepAliveInterval is longer than 60 seconds
proxy_read_timeout 100s;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
full documentation is on SignalR [documentaion][1]
[1]: https://docs.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-5.0
title | description | author | ms.service | ms.topic | ms.date | ms.author | ms.openlocfilehash | ms.sourcegitcommit | ms.translationtype | ms.contentlocale | ms.lasthandoff | ms.locfileid |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Руководство по устранению неполадок для Службы Azure SignalR |
Сведения об устранении распространенных неполадок |
yjin81 |
signalr |
conceptual |
11/06/2020 |
yajin1 |
e26def56fbd03626c3efc660db57012ee1b767ea |
ed7376d919a66edcba3566efdee4bc3351c57eda |
MT |
ru-RU |
03/24/2021 |
105048210 |
Руководство по устранению неполадок службы Azure SignalR
Это руководство содержит полезные рекомендации по устранению неполадок на основе распространенных проблем, которые пользователи составили и устраняют за последние годы.
Слишком длинный маркер доступа
Возможные ошибки
- На стороне клиента
ERR_CONNECTION_
- 414 — слишком длинный универсальный код ресурса (URI)
- 413 (слишком большой объем полезных данных)
- Длина маркера доступа не должна превышать 4 КБ. 413 — размер запрашиваемой сущности слишком большой
Первопричина
Для HTTP/2 Максимальная длина для одного заголовка равна 4 КБ, поэтому при использовании браузера для доступа к службе Azure произойдет ошибка ERR_CONNECTION_
для этого ограничения.
Для клиентов HTTP/1.1 или C# максимальная длина URI составляет 12 КБ, максимальная длина заголовка — 16 КБ.
При использовании пакета SDK версии 1.0.6 или более поздней /negotiate
выдается исключение, 413 Payload Too Large
Если созданный маркер доступа больше 4 КБ.
Решение
По умолчанию утверждения из context.User.Claims
включаются при создании маркера доступа JWT для АСРС(Zure игнал R s ервице), чтобы утверждения сохранялись и можно было передавать из АСРС в, Hub
когда клиент подключается к Hub
.
В некоторых случаях context.User.Claims
используется для хранения большого количества сведений для сервера приложений, большинство из которых не используются, Hub
а другими компонентами.
Созданный маркер доступа передается через сеть, а для соединений WebSocket и SSE маркеры доступа передаются через строки запроса. Поэтому мы рекомендуем передавать на сервер приложений только необходимые утверждения от клиента через АСРС , когда это необходимо.
ClaimsProvider
Для настройки утверждений, передаваемых в АСРС внутри маркера доступа, можно настроить.
Для ASP.NET Core:
services.AddSignalR() .AddAzureSignalR(options => { // pick up necessary claims options.ClaimsProvider = context => context.User.Claims.Where(...); });
Для ASP.NET:
services.MapAzureSignalR(GetType().FullName, options => { // pick up necessary claims options.ClaimsProvider = context.Authentication?.User.Claims.Where(...); });
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Требуется TLS 1,2
Возможные ошибки
- ASP.NET об ошибке «сервер недоступен» #279
- ASP.NET «Подключение неактивно, данные не могут быть отправлены в службу». #324 об ошибке
- «Произошла ошибка при выполнении HTTP-запроса к https:// . Эта ошибка может быть вызвана тем, что сертификат сервера неправильно настроен с HTTP.SYS в случае HTTPS. Эта ошибка также может быть вызвана несоответствием привязки безопасности между клиентом и сервером. «
Первопричина
Служба Azure поддерживает только TLS 1.2 в целях безопасности. В .NET Framework возможно, что TLS 1.2 не является протоколом по умолчанию. В результате невозможно успешно установить подключения сервера к АСРС.
Руководство по устранению неполадок
-
Если эту ошибку можно воспроизвести локально, снимите флажок только мой код и вызывайте все исключения CLR и отлаживать сервер приложений локально, чтобы увидеть, что вызывает исключение.
-
Снять только мой код
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/uncheck-just-my-code.png» alt-text=»Снять Только мой код»:::
-
Выдавать исключения CLR
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/throw-clr-exceptions.png» alt-text=»Выдавать исключения CLR»:::
-
См. исключения, возникающие при отладке кода на стороне сервера приложений:
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/tls-throws.png» alt-text=»Исключение»:::
-
-
Для ASP.NET можно также добавить следующий код в,
Startup.cs
чтобы включить подробную трассировку и просмотреть ошибки из журнала.app.MapAzureSignalR(this.GetType().FullName); // Make sure this switch is called after MapAzureSignalR GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;
Решение
Добавьте в запуск следующий код:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
400 для клиентских запросов возвращен неверный запрос
Первопричина
Проверьте, содержит ли ваш запрос клиента несколько hub
строк запроса. hub
сохраненный параметр запроса, и 400 выдаст исключение, если служба обнаружит hub
в запросе более одного.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
401 Unauthorized returned for client requests (Возврат ошибки с кодом «401 — не санкционировано» для клиентских запросов)
Первопричина
В настоящее время время жизни маркера JWT по умолчанию — 1 час.
Для ASP.NET Core SignalR, когда он использует тип транспорта WebSocket, это нормально.
Для другого типа транспорта ASP.NET Core SignalR, SSE и длительного опроса, это означает, что по умолчанию подключение может храниться не более 1 часа.
Для ASP.NET SignalR клиент отправляет /ping
службе запрос на KeepAlive время от времени, когда /ping
происходит сбой, клиент прерывает подключение и никогда не переключается. Это означает, что для ASP.NET SignalR время существования токена по умолчанию делает подключение продолжительностью не более 1 часа для всех типов транспорта.
Решение
В целях безопасности не рекомендуется расширять TTL. Мы рекомендуем добавить логику повторного подключения из клиента, чтобы перезапустить подключение при возникновении такой ошибки 401. Когда клиент перезапускает подключение, он будет согласовываться с сервером приложений для повторного получения маркера JWT и получения обновленного маркера.
Установите здесь , чтобы перезапустить клиентские подключения.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
404 returned for client requests (Возврат ошибки с кодом 404 для клиентских запросов)
Для постоянного подключения SignalR сначала /negotiate
необходимо установить службу Azure SignalR, а затем — реальное подключение к службе Azure SignalR.
Руководство по устранению неполадок
- Чтобы Просмотреть исходящие запросы на получение запроса от клиента к службе, необходимо выполнить следующие требования.
- Проверьте URL-адрес запроса при возникновении ошибки 404. Если URL-адрес предназначен для веб-приложения и аналогичен
{your_web_app}/hubs/{hubName}
, проверьте, имеет ли клиентSkipNegotiation
true
. При использовании Azure SignalR клиент получает URL-адрес перенаправления при первом согласовании с сервером приложений. Клиент не должен пропускать согласование при использовании Azure SignalR. - Еще один 404 может произойти, когда запрос на подключение обрабатывается более 5 секунд после
/negotiate
вызова. Проверьте метку времени запроса клиента и откройте сообщение о том, что в случае, если запрос к службе имеет слишком много откликов.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
404 возвращается для запроса на повторное подключение SignalR ASP.NET
Для ASP.NET SignalR при удалении клиентского соединенияон повторно подключается в connectionId
течение трех раз, прежде чем остановить подключение. /reconnect
может помочь, если подключение отбрасывается из-за временных неполадок сети, которые /reconnect
могут успешно восстановить постоянное подключение. В других случаях, например, подключение клиента отбрасывается из-за разрыва соединения с перенаправленным сервером, или служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа или развертывание, поэтому соединение больше не существует, поэтому /reconnect
возвращается 404
. Это ожидаемое поведение в /reconnect
и после трех раз, когда повторная попытка подключения прекращается. Мы рекомендуем подать логику перезапуска подключения при остановке соединения.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
429 (слишком много запросов) возвращено для клиентских запросов
Есть два способа.
Число одновременных подключений превышает предел
Для свободных экземпляров ограничение числа одновременных подключений равно 20 для стандартных экземпляров, ограничение числа одновременных подключений на единицу равно 1 K, что означает, что Unit100 допускает одновременные подключения 100-K.
Подключения включают как клиентские, так и серверные соединения. Проверьте , как подсчитываются подключения.
Слишком много запросов на согласование одновременно
Мы рекомендуем установить произвольную задержку перед повторной попыткой подключения, чтобы проверить примеры повторных попыток.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
500 ошибка при согласовании: служба Azure SignalR еще не подключена, повторите попытку позже.
Первопричина
Эта ошибка возникает при отсутствии подключения сервера к службе SignalR Azure.
Руководство по устранению неполадок
Включите трассировку на стороне сервера, чтобы узнать сведения об ошибке, когда сервер пытается подключиться к службе Azure SignalR.
Включение ведения журнала на стороне сервера для ASP.NET Core SignalR
Ведение журнала на стороне сервера для ASP.NET Core SignalR интегрируется с ILogger
журналом на основе ASP.NET Core Framework. Вы можете включить ведение журнала на стороне сервера с помощью ConfigureLogging
, выбрав пример использования следующим образом:
.ConfigureLogging((hostingContext, logging) => { logging.AddConsole(); logging.AddDebug(); })
Категории средств ведения журнала для Azure SignalR всегда начинаются с Microsoft.Azure.SignalR
. Чтобы включить подробные журналы из Azure SignalR, настройте предыдущие префиксы для Debug
уровня appsettings.jsв файле, как показано ниже:
{ "Logging": { "LogLevel": { ... "Microsoft.Azure.SignalR": "Debug", ... } } }
Включение трассировки на стороне сервера для ASP.NET SignalR
При использовании пакета SDK версии >= 1.0.0
можно включить трассировку, добавив следующую команду в web.config
: (Details).
<system.diagnostics> <sources> <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch"> <listeners> <add name="ASRS" /> </listeners> </source> </sources> <!-- Sets the trace verbosity level --> <switches> <add name="SignalRSwitch" value="Information" /> </switches> <!-- Specifies the trace writer for output --> <sharedListeners> <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" /> </sharedListeners> <trace autoflush="true" /> </system.diagnostics>
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Разрывы соединения с клиентом
Когда клиент подключается к Azure SignalR, постоянное подключение между клиентом и Azure SignalR иногда может быть удалено по разным причинам. В этом разделе описываются некоторые возможности, вызывающие такое удаление подключения, и приводятся некоторые рекомендации по определению основной причины.
Возможные ошибки со стороны клиента
The remote party closed the WebSocket connection without completing the close handshake
Service timeout. 30.00ms elapsed without receiving a message from service.
{"type":7,"error":"Connection closed with an error."}
{"type":7,"error":"Internal server error."}
Первопричина
Клиентские подключения могут удаляться при различных обстоятельствах:
- При
Hub
вырождении исключений с входящим запросом. - Когда соединение с сервером, на которое направляется клиент, удаляется, см. ниже в разделе с подробными сведениями о падении соединения с сервером.
- При возникновении проблемы с сетевым подключением между клиентом и службой SignalR.
- Когда служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа, развертывание и т. д.
Руководство по устранению неполадок
- Откройте журнал на стороне сервера приложений, чтобы проверить, не произошло ли что-либо непредвиденное
- Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
- Создайте ошибку, предоставляющую время, и отправьте имя ресурса по адресу
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Подключение клиента постоянно увеличивается
Это может быть вызвано неправильным использованием клиентского соединения. Если кто-то забыл закрыть или ликвидировать клиент SignalR, соединение остается открытым.
Возможные ошибки в метриках SignalR, которые находятся в разделе «Мониторинг» портал Azure меню ресурсов
Клиентские подключения постоянно наиграют в течение длительного времени в метриках Azure SignalR.
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/client-connection-increasing-constantly.jpg» alt-text=»Подключение клиента постоянно растет»:::
Первопричина
Подключение клиента SignalR DisposeAsync
никогда не вызывается, подключение остается открытым.
Руководство по устранению неполадок
Проверьте, не закрывается ли клиент SignalR.
Решение
Убедитесь, что подключение закрыто. Вызов метода HubConnection.DisposeAsync()
останавливает подключение вручную после его использования.
Пример:
var connection = new HubConnectionBuilder() .WithUrl(...) .Build(); try { await connection.StartAsync(); // Do your stuff await connection.StopAsync(); } finally { await connection.DisposeAsync(); }
Распространенное неправильное использование подключения клиента
Пример функции Azure
Эта проблема часто возникает, когда кто-то устанавливает клиентское подключение SignalR в методе функции Azure вместо того, чтобы сделать его статическим членом класса функции. Вы можете ожидать, что установлено только одно клиентское подключение, но количество подключений клиентов постоянно увеличивается в метриках, которые находятся в разделе «Мониторинг» в портал Azure меню ресурсов. все эти подключения отменяются только после перезапуска функции Azure или службы Azure SignalR. Это связано с тем, что при каждом запросе функция Azure создает одно клиентское соединение, если подключение клиента в методе функции не будет прервано, клиент будет поддерживать подключения в службе Azure SignalR.
Решение
- Не забудьте закрыть клиентское подключение, если вы используете SignalR Clients в функции Azure или используете клиент SignalR в качестве одноэлементного.
- Вместо использования клиентов SignalR в функции Azure вы можете создавать клиенты SignalR в любом месте и использовать привязки функций Azure для службы Azure SignalR для согласования клиента с Azure SignalR. Кроме того, можно использовать привязку для отправки сообщений. Примеры для согласования клиентов и отправки сообщений можно найти здесь. Дополнительные сведения можно найти здесь.
- При использовании клиентов SignalR в функции Azure может быть улучшена архитектура вашего сценария. Проверьте, правильно ли разрабатывается бессерверная архитектура. Вы можете обращаться к бессерверным приложениям в режиме реального времени с привязками службы SignalR в функциях Azure.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Падения подключений к серверу
Когда сервер приложений запускается, в фоновом режиме пакет SDK для Azure начинает инициировать подключения к удаленному серверу Azure SignalR. Как описано в статье внутренние компоненты службы Azure SignalR, Azure SignalR направляет входящие клиентские трафик на эти подключения к серверу. После удаления соединения с сервером все клиентские подключения, которые он обслуживает, будут закрыты.
Поскольку подключения между сервером приложений и службой SignalR являются постоянными подключениями, они могут испытывать проблемы с сетевым подключением. В пакете SDK для сервера мы всегда повторно подключаем стратегию к подключениям к серверу. Рекомендуется также рекомендовать пользователям добавлять логику непрерывного повторного подключения к клиентам с произвольным временем задержки, чтобы избежать массовых одновременных запросов к серверу.
На регулярной основе для службы Azure SignalR предусмотрены новые версии версий, а иногда установка исправлений или обновления операционной системы для всего Azure, а также иногда прерывание от наших зависимых служб. Это может привести к кратковременному прерыванию работы службы, но при условии, что клиент на стороне клиента имеет механизм отключения и повторного подключения, такое влияние минимально, как и на стороне клиента, вызванного отключением и повторному подключению.
В этом разделе описаны несколько возможностей, ведущих к удалению подключения к серверу, и приводятся некоторые рекомендации по определению основной причины.
Возможные ошибки со стороны сервера
[Error]Connection "..." to the service was dropped
The remote party closed the WebSocket connection without completing the close handshake
Service timeout. 30.00ms elapsed without receiving a message from service.
Первопричина
Подключение к службе сервера закрыто АСРС(A Zure игнал****R s ервице).
Для времени ожидания проверки связи это может быть вызвано высокой нагрузкой ЦП или нехватка пула потоков на стороне сервера.
В ASP.NET SignalR была исправлена известная проблема в пакете SDK 1.6.0. Обновите пакет SDK до последней версии.
Нехватка ресурсов пула потоков
Если сервер не используется, это означает, что потоки не работают над обработкой сообщений. Все потоки не отвечают в определенном методе.
Обычно этот сценарий вызывается асинхронно для синхронизации или Task.Result
/ Task.Wait()
в асинхронных методах.
См. ASP.NET Core рекомендации по повышению производительности.
См. Дополнительные сведения о нехватке пула потоков.
Как определить нехватку пула потоков
Проверьте число потоков. Если в это время нет пиковых нагрузок, сделайте следующее:
-
Если вы используете службу приложений Azure, проверьте количество потоков в метриках. Проверьте
Max
агрегирование::::image type=»content» source=»media/signalr-howto-troubleshoot-guide/metrics-thread-count.png» alt-text=»Снимок экрана: панель «максимальное число потоков» в службе приложений Azure.»:::
-
Если вы используете платформа .NET Framework, вы можете найти метрики в системном мониторе на виртуальной машине сервера.
-
Если вы используете .NET Core в контейнере, см. раздел получение диагностических сведений в контейнерах.
Можно также использовать код для обнаружения недостаточности пула потоков:
public class ThreadPoolStarvationDetector : EventListener { private const int EventIdForThreadPoolWorkerThreadAdjustmentAdjustment = 55; private const uint ReasonForStarvation = 6; private readonly ILogger<ThreadPoolStarvationDetector> _logger; public ThreadPoolStarvationDetector(ILogger<ThreadPoolStarvationDetector> logger) { _logger = logger; } protected override void OnEventSourceCreated(EventSource eventSource) { if (eventSource.Name == "Microsoft-Windows-DotNETRuntime") { EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All); } } protected override void OnEventWritten(EventWrittenEventArgs eventData) { // See: https://docs.microsoft.com/en-us/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment && eventData.Payload[3] as uint? == ReasonForStarvation) { _logger.LogWarning("Thread pool starvation detected!"); } } }
Добавьте его в службу:
service.AddSingleton<ThreadPoolStarvationDetector>();
Затем проверьте журнал, когда соединение с сервером отключается по истечении времени ожидания проверки связи.
Как найти основную причину нехватка ресурсов пула потоков
Чтобы найти основную причину нехватка ресурсов пула потоков, выполните следующие действия.
- Выведите дамп памяти, а затем проанализируйте стек вызовов. Дополнительные сведения см. в разделе Получение и анализ дампов памяти.
- Используйте клрмд для дампа памяти при обнаружении нехватки ресурсов пула потоков. Затем зайдите в журнал стека вызовов.
Руководство по устранению неполадок
- Откройте журнал на стороне сервера приложений, чтобы проверить, не выполнялось ли что-либо непредвиденное.
- Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
- Создайте вопрос. Укажите интервал времени и отправьте имя ресурса по электронной почте.
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Советы
- Как просмотреть исходящий запрос от клиента?
Возьмем ASP.NET Core один пример (ASP.NET похож):-
Из браузера:
Возьмем Chrome в качестве примера. можно использовать F12 , чтобы открыть окно консоли, и перейти на вкладку сеть . Возможно, потребуется обновить страницу с помощью клавиши F5 , чтобы захватить сеть с самого начала.
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/chrome-network.gif» alt-text=»Сеть представления Chrome»:::
-
Из клиента C#:
Вы можете просматривать локальные веб-трафик с помощью Fiddler. Трафик WebSocket поддерживается с момента Fiddler 4,5.
:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network-inline.png» alt-text=»Fiddler просмотр сети» lightbox=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network.png»:::
-
-
Как перезапустить клиентское подключение?
Ниже приведены примеры кодов , содержащих перезапуск логики подключения с использованием всегда стратегии повторных попыток :
-
Клиент ASP.NET Core C#
-
ASP.NET Core клиент JavaScript
-
Клиент ASP.NET C#
-
Клиент ASP.NET JavaScript
-
Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.
Дальнейшие действия
В этом руководство вы узнали, как решать распространенные проблемы. Вы также можете узнать больше об общих методах устранения неполадок.
[!div class=»nextstepaction»]
Устранение проблем с подключением и доставкой сообщений