Мы обновляем cometd с версии 2.5 до 3.0.9, но с отключенными веб-сокетами. Одно из изменений, которые мы заметили, это: метод org.cometd.server.ServerSessionImpl disconnect() больше не устанавливает флаг успешного сообщения перед его публикацией в канале «/meta/disconnect». Замечено в репозитории GitHub cometd, что он был удален как часть фиксации 14 октября 2015 г. — Улучшена обработка отключений на стороне сервера (пользователь sbordet).
public void disconnect()
{
boolean connected = _bayeux.removeServerSession(this, false);
if (connected)
{
ServerMessage.Mutable message = _bayeux.newMessage();
message.setChannel(Channel.META_DISCONNECT);
// message.setSuccessful(true);
deliver(this, message);
flush();
}
}
Теперь на стороне клиента мы используем jquery для взаимодействия с cometd (jquery.cometd.js). Мы запускаем переподключение всякий раз, когда получаем сообщение об отключении от кометда со стороны сервера. Мы проверяем следующее условие перед попыткой повторного подключения.
$.cometd.isDisconnected() && (message.channel == "/meta/disconnect" && message.successful)
Проверка message.successful завершается ошибкой, так как она никогда не устанавливается на стороне сервера из-за изменения API отключения. Следовательно, сеанс никогда не переподключается/не восстанавливается, что приводит к тому, что сервер вообще не знает об этом сеансе, и, следовательно, серверная сторона не отправляет какие-либо служебные сообщения сервера на клиентскую сторону.
Мы хотим сохранить эту проверку, так как во время выхода из системы этот флаг успешно установлен. Во время выхода из системы мы вызываем приведенный ниже метод на стороне клиента, который, в свою очередь, вызывает вызов DisconnectHandler на стороне сервера (под BayeuxServerImpl). Событие сообщения DisconnectHandler устанавливает этот флаг в значение true в ответном сообщении.
$.cometd.disconnect()
Во-первых, нужно понять, почему флаг успеха больше не устанавливается в сообщении об отключении Cometd, когда отключение инициируется со стороны сервера (ожидается, что это будет соответствовать поведению DisconnectHandler). Во-вторых, есть ли возможная альтернатива установке этого флага, т.е. может быть переопределение либо на стороне клиента, либо на стороне сервера?
