Изящная обработка времени ожидания сервера в BlazeDS

Question

У меня есть гибкий клиент, который выполняет сервисные вызовы на сервер Tomcat, на котором работает BlazeDS. Я хотел бы изящно обрабатывать тайм-ауты сеансов сервера в этой среде.

У меня есть ограничения безопасности для службы, поэтому клиент аутентифицируется на удаленном объекте, инициализируя ChannelSet на основе пункта назначения, а затем входя в систему с использованием этого ChannelSet.

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

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

Но мне трудно найти лучший способ обнаружить это время ожидания у клиента. Возможно ли, или мне нужно, чтобы сервер выдавал ошибку при истечении времени ожидания?

Спасибо!

Answer 1

Мы внедрили службу пользовательского интерфейса, которая постоянно пингует сервер (1 пинг в 10 минут), тем самым предотвращая разрыв соединения AppServer. Мы также запускаем некоторый внутренний таймер пользовательского интерфейса, который сбрасывается каждый раз, когда делается любой запрос (кроме «ping»), с полной функцией, вызывающей пользовательский интерфейс, чтобы переключиться обратно на вход в систему и показать «Сеанс истек из-за неактивности клиента».

Answer 2

Это не относится к BlazeDS, но в Flex 4.5 (возможно, ранее) в событии сбоя есть специальный код ошибки для ошибок тайм-аута:

В вашем обработчике ошибок:

if(faultEvent.fault.faultCode == "Client.Error.RequestTimeout"){
  trace("TIMEOUT ERROR");
}

Answer 3

Мы написали пользовательский компонент для клиента, который фиксирует нажатия клавиш и события мыши, а затем обрабатывает таймауты на клиенте.

Answer 4

Расширьте CallResponder и переопределите метод ошибки.

Проверьте data.fault.faultCode на наличие известных кодов ошибок, таких как ErrorMessage.MESSAGE_DELIVERY_IN_DOUBT.

Если вы получили удар, используйте встроенную функцию navigateToURL для перенаправления.

Answer 5

Реализация интерфейса FlexSessionListener на стороне сервера. Он обеспечивает способ обработки создания / уничтожения сеансов Flex до того, как они фактически будут выполнены.

В обработчике sessionDestroyed используйте Messaging Producer, чтобы отправить сообщение с сервера клиенту, сообщив ему, что время сеанса истекло.

Answer 6

Я столкнулся с этой проблемой в одном из моих проектов. Чтобы преодолеть это, я каждый раз, когда клиентский доступ к серверу, либо через RemoteObject, либо через HTTPService, сначала проверяет аутентификацию пользователя, если его время уже истекло, он что-то возвращает и, если все нормально, продолжает процесс. В событии результата обработчика ответа на стороне клиента клиент проверяет, является ли ответ истечением времени ожидания, и если это так, он переадресует страницу входа снова. Насколько я знаю, сервер не выдаст ошибку клиенту, когда истечет время ожидания сеанса пользователя. Вы просто узнаете время ожидания сеанса при следующем доступе к серверу.

Answer 7

Я столкнулся с этой проблемой в проекте, особенно потому, что время ожидания сеанса BlazeDS отличалось от фактического приложения (при использовании архитектуры единого входа через ClearTrust). Следует отметить, что это было в среде JBoss. В итоге я выбрал довольно простой подход, ища 2 конкретных кода ошибки в обработчиках ошибок (имел базовый класс с общим обработчиком ошибок): DuplicateSessionDetected и DeliveryInDoubt. Я видел DuplicateSessionDetected всякий раз, когда BlazeDS пытался создать новый сеанс для того же идентификатора сеанса JBoss. DeliveryInDoubt, как правило, иногда появлялся, но я не уверен почему. Когда я увидел эти коды ошибок, я предпринял необходимые действия для обновления приложения (в зависимости от ваших потребностей вы можете перенаправить на страницу входа или что-то еще). Очевидно, что в зависимости от среды вам, возможно, придется прислушиваться к другому коду ошибки, и этот подход может не работать в каждой ситуации, учитывая разные среды / конфигурации / и т. Д.

Другой подход, который обсуждался, заключался в использовании таймера в приложении Flex, который представлял бы таймер тайм-аута BlazeDS, но я не фанат использования таймеров для этой цели. Я также слышал об отправке небольшого количества данных назад и вперед на сервер для проверки тайм-аута, но опять же, это казалось не идеальным.

Answer 8

Посмотрите документы и посмотрите, происходит ли событие при разрыве соединения. Я бы предположил, что есть. Если нет, используйте try / catch для ваших подключений и выявляйте любые проблемы, связанные с подключением. Если вы это сделаете, перенаправьте ваше приложение и уведомите пользователя. Возможно, вам придется поиграть с ним, чтобы найти точные коды ошибок, возникающие из-за проблем с соединением, но это должно быть довольно легко при отладке.