Соединение SignalR замораживает другие запросы ajax

У меня есть другое объяснение того, что могло вызвать проблему.

Поскольку вопрос был задан в 2013 году, я предполагаю, что автор уже нашел решение своей проблемы. Но так как мне понадобилось несколько часов, чтобы копаться в своей, считаю своим долгом поделиться своим опытом.

Обзор архитектуры: приложение Asp.Net SPA с AngularJS на стороне клиента и WebApi 2.0 и SignalR 2.1 на стороне сервера.

Симптомы проблемы: приложение запускается и работает нормально, но через некоторое время все запросы (SignalR и WebApi) зависают. Под «зависанием» я подразумеваю, что запросы WebApi выполняются на клиенте, но методы контроллера никогда не вызываются. Первым зависает всегда запрос SignalR.

После некоторого поиска я нашел наиболее вероятную причину этих симптомов. Это была проблема «Блокировка состояния сеанса», подробно описанная в это сообщение Джона Калвинера.

Поскольку мое приложение не использовало сеансы, я просто переключил их в режим только для чтения на уровне приложения:

protected void Application_Start()
{
    // Some extra initialization here
    Context.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.ReadOnly);
}

Это не помогло.

Я продолжил свои исследования и считаю, что к тому времени я прочитал все статьи или отчеты об ошибках с ключевыми словами SignalR, соединение, зависание, зависание, зависание. Ничего похожего на мой случай не было. Поэтому вместо того, чтобы искать, в чем может быть проблема с используемой технологией, я начал анализировать, что может быть не так с моим собственным кодом. И вот оно.

У моей проблемы есть хорошее описание в этом статья Шона. Вот обзор. В стандартном мире MVC SignalR сам управляет своим соединением. Он отключится автоматически, когда вы перейдете на другую страницу. Таким образом, вы можете просто создать соединение и забыть об этом. К сожалению, это не так для приложений SPA/AngularJS. Соединение SignalR никогда не узнает, что страница внутри SPA была изменена, и никогда не отключится. Когда вы вернетесь на страницу, будет создано новое подключение SignalR. По моим наблюдениям, вам нужно сделать это около 10 раз, чтобы канал, обслуживающий запросы, застрял.

Итак, все, что вам нужно сделать здесь, это создать функцию остановки для подключения SignalR и вызвать ее вручную перед изменением страницы внутри SPA:

stop: function() {
    if (connection && connection.state && connection.state !== 4 /* disconnected */) {
        connection.stop();
    }
},

В контроллере:

$scope.$on('$destroy', function() {
    clientPushHubProxy.stop();
});

Если взять ответ @bjornhol немного дальше - та же проблема со всеми запросами SignalR (которые загружали больше AJAX) возникала и у меня. Я думал, что проблема в jQuery, но на самом деле это состояние сеанса. Для этого контроллера, если вы можете установить SessionStateBehaviour в ReadOnly или Disabled, вы увидите, что запросы выполняются одновременно. См. также эту ссылку http://johnculviner.com/asp-net-concurrent-ajax-requests-and-session-state-blocking/ Надеюсь, это поможет.