2015-02-23 5 views
2

По какой-то причине SignalR просто прекратит вызов клиентских методов через короткий промежуток времени (примерно 1 час или менее, я оцениваю). У меня есть страница, на которой отображаются предупреждения ... очень простая реализация. Вот Javascript:SignalR останавливает работу после A

$(function() { 

    // enable logging for debugging 
    $.connection.hub.logging = true; 

    // Declare a proxy to reference the hub. 
    var hub = $.connection.alertHub; 

    hub.client.addAlert = function (id, title, url, dateTime) { 
     console.log(title); 
    }; 

    $.connection.hub.start().done(function() { 
     console.log("Alert Ready"); 
    }); 
}); 

Если я обновить страницу, она снова работает в течение часа, затем прекратить называть событие клиента addAlert. В журнале нет ошибок, никаких предупреждений. Последнее событие в журнале (кроме пингов на сервер) является:

[15:18:58 GMT-0600 (CST)] SignalR: Запуск клиента ступицу событие 'addAlert' на ступице 'AlertHub' ,

Многие из этих событий появятся ненадолго, а затем просто остановитесь, хотя сервер все равно должен их отправлять.

Я использую Firefox 35.0.1 на Mac и SignalR 2.0.0.

Я понимаю, что обход - это заставить обновлять страницу каждые 10 минут или около того, но я ищу способ исправить основную причину проблемы.

Я включил трассировку SignalR на сервере. Я создал «предупреждение» на сервере после нового обновления страницы «Предупреждение» и появилось предупреждение. Я ждал около 10 минут, и я попробовал еще раз, и он не смог пройти. Вот то, что журналы чтения (извините за многословие, не уверен, что имеет отношение):

SignalR.Transports.TransportHeartBeat Information: 0 : Connection b8b21c4c-22b4-4686-9098-cb72c904d4c9 is New. 
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9) 
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9) 
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9) 
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9) 

Есть еще несколько десятков из SignalR.Transports.TransportHeartBeat сообщений, но ничего.

+1

Установили ли вы журналы в концентраторе на стороне сервера, чтобы узнать, отключен ли ваш клиент до остановленных действий? –

+0

У меня нет. Я сделаю это и опубликую результаты. Благодарю. –

+0

Помимо журналов. Какой транспорт вы используете, и вы проходите через прокси? Если да, попробовали ли вы использовать https? – Pawel

ответ

0

Как выясняется, проблема была, как я обрабатывал в AlertHub соединения. Я использую кэширование корпоративной библиотеки для хранения соединений, поддерживающих AlertHub, и я истекал через 20 минут после того, как они были созданы. Ergo, когда сервер вызывал клиентский метод, никаких ошибок, о которых сообщалось, поскольку не было клиентов (-ов) для отправки сообщений.

С тех пор я увеличил срок действия кеша до разумного значения, которое решило проблему.

+0

Можете ли вы опубликовать код/​​файл, где вы это сделали? Я думаю, что у меня такая же проблема. Весьма признателен. – toddmo

0

Вы можете обновить страницу, если клиент неактивен, без движения мыши (примерно каждые 15-30 минут). У меня была такая же проблема, и я решил это так. Это было неприятное обходное решение, но позже я забыл об этом и никогда не исправил его полностью;)

+0

Thats a hack not a solution – Anders

+0

Любая идея о первопричине? –

+0

@ RandonBoy, вы используете пользовательский преобразователь зависимостей для SignalR? –

0

Я думаю, что это время ожидания по умолчанию 110 секунд для signalr. Можете ли вы попробовать отключить событие signalr, чтобы снова подключить его.

$.connection.hub.disconnected(function() { 
      setTimeout(function() { 
       startHub(); 
      }, 5000); 
     }); 

и в startHub() вы можете начать соединение еще раз.

ссылка: https://github.com/SignalR/SignalR/issues/3128

и How to use SignalR events to keep connection alive in the right way?

+0

Я дам этот снимок и опубликую результаты. Спасибо. –

+1

Тайм-аут в 110 секунд используется только для длительного запроса опроса, чтобы предотвратить прокси-серверы от прерывания длинных HTTP-запросов. Запрос опроса будет закрыт через 110 секунд, и будет создан новый запрос опроса, и это не должно вызывать повторные подключения/разъединения, так как это длительный опрос. Этот тайм-аут не относится к другим транспортом (хорошо, я не уверен, что навсегда транспорт кадра) – Pawel

+0

любой прогресс? Мне сейчас интересно. Утилизация пула приложений влияет на это, как заявил Джейсон. –

Смежные вопросы