Корректная обработка тайм-аута сервера в BlazeDS

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

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

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

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

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

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

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