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. После обновления библиотек даже этот механизм перестал работать. Что делать, куда смотреть?