Flex - BlazeDS - Java: контроль присутсвия клиента

[Dimitry_II]

Сушу себе голову ...
Сделал messaging через канал streaming-amf (Producer & Consumer). Основной функционал, для которого мне нужен был messaging, отлично работает - клиент подписывается и получает уведомления с сервера без задержек и по возникновению серверных событий (server push).
Однако я хотел также посредством данной "штуки" контролировать "присутствие клиента в системе" типа того, как это происходит с сокетным соединением, когда при "отваливании" клиента сервер об этом тут же узнает, вне зависимости от способа отключения. Но как этого добиться, я не представляю, хотя раз пользователь подписан, то, надо полагать, канал установлен и при его разрыве что-то должно реагировать.
Подскажите, плиз, можно ли это сделать? Если нет, то каким еще образом я могу осуществлять такой контроль? (поллинг совершенно не хочу использовать, также создавать свой Socket не хотелось бы).

Добавлено через 21 минуту
Из описания:

StreamingAMFChannel / StreamingAMFEndpoint
Uses the HTTP 1.1 ‘chunked’ server push model instead of polling for data
from the server. An internal HTTP connection to the server is held open
so the server can stream data to the client with little overhead. Cannot be
compressed or proxied.

Я такое делал ручками (только используя NIO) и это действительно открытый постоянный сокет, где происходит обмен порциями данных - "chunk". При подписывании на получение уведомлений сокет создается, при отказа - закрывается. В любом случае, при создании такой штуки я получал собитие на сервере и при подключении, и при получении данных, и при ошибках связи, и при потери связи, и при дисконнекте.

Уверен, что и тут можно как-то побороть это, но пока непонятно как.

Добавлено через 32 часа 3 минуты
Ну полный беспредел ...
Нашел такую штуку: если в кастомном адаптере, расширяющем базовый ServiceAdapter, переопределить метод
@Override
public boolean handlesSubscriptions() {
return true;
}
то внутренний менеджер начнет получать все сообщения
@Override
public Object manage(CommandMessage commandMessage) {
System.out.println("Manage got message.");
return null;
}
Переменная commandMessage имеет свойство getOperation(), где можно получить код. При отключении вываливается с чем-то типа UNSUBSCRIBE.

То есть задуманное сработало, только вот получаю это сообщение (реакцию на дисконнект) через 63-64 секунды (3-4 секунды даю на погрешности и на срабатывание дебаггера). Пытался отыскать что отвечает за эту "паузу" - не нашел. Так как до сих пор использовал BlazeDS 3, то решил перейти на 4. После обновления библиотек даже этот механизм перестал работать. Что делать, куда смотреть?

[vola62]

Я тоже не нашёл решения - чтоб красиво обновить список сразу при дисконнекте. Что я сделал - так - это что каждый клиент через каждые несколько сек (примерно 30 - не помню точно) - шлёт на сервер - "я живой" - и тот запоминает(true) и где-то раз в 25 сек - обходит список. - если не живой - говорит всем заинтересованным - что такой-то отвалился...

[Dimitry_II]

Не, это даже не костыль, это гналая заплатка , которую стыдно вставлять в мало-мальски серьезный проект.
Проблема решена, причем, самостоятельно. Решение публиковать тут не буду, оно есть на форуме sql.ru в разделе Java. Решение получилось скорее интуитивно и методом множественного тыка, но работает! (Задержка в 1-2 секунды не в счет)