Apache Curator (Scala) Новый сеанс при переподключении без изменения состояния LOST
Мы наблюдали следующее поведение и не уверены, является ли это известной ошибкой или просто неправильной конфигурацией или неправильным использованием библиотеки.
- Использование куратор-фреймворка 2.7.0 библиотеки Scala, zookeeper-3.4.5
- Запустите приложение scala, которое подключается к локальному серверу zk по адресу 127.0.0.1:2181. Мы воспроизвели это с различными политиками повторения, но для простоты предположим, что наша политика повторов спит в течение 30 секунд и повторяется бесконечно.
- Хвост как журналы приложений Scala и журналы локального сервера zk
- Запустите "sudo iptables -A OUTPUT -p tcp --dport 2181 -j DROP" и подождите.
- В конце концов, в журнале приложений Scala появляются журналы изменений состояния SUSPENDED.
- В конечном итоге журналы "Session expiration" появляются в журналах zk-сервера. Если мы поднимем iptables, приложение scala зарегистрирует LOST, а затем RECONNECTED. Это то, что мы ожидаем.
- Если вместо этого мы продолжим ждать вместо того, чтобы поднимать iptables сразу после того, как сервер зарегистрирует SessionExpiration, мы увидим, что в журнале происходят события retryPolicy и происходит сбой. Все еще ожидается, насколько я могу судить.
- Проблема в том, что мы поднимаем iptables через "долгое время", после которого происходит несколько повторных попыток. Здесь, по-видимому, происходит повторное соединение с новым идентификатором сеанса и без изменения состояния LOST. Конечным результатом является то, что мы подключены, но потеряли все временные данные и не пытаемся восстановить их, потому что эта логика была связана с изменением состояния LOST.
Похоже, что это как-то связано с идентификатором сеанса клиента "тайм-аут" или "очистка", так что переподключение сервера предполагает, что клиент уже знает, что сеанс истек. Есть подтверждение? Наша текущая идея состоит в том, чтобы кэшировать идентификатор сессии до и после и моделировать наше собственное изменение состояния LOST, но похоже, что мы боремся с API.
Спасибо
1 ответ
Состояния подключения куратора напрямую не связаны со стандартными событиями ZooKeeper. Таким образом, LOST не означает потерю сессии ZK. Это означает, что куратор считает, что соединение было потеряно из-за ваших настроек повтора и т. Д. См. Раздел "Уведомления" здесь: http://curator.apache.org/errors.html