Проблема с отказом Tibco-Ems

Question

У меня есть 2 сервера Tibco-Ems с отказоустойчивой настройкой. Если один сервер недоступен, активный сервер переключается на сервер отказоустойчивости, как ожидалось.

Однако время от времени я получаю странные ошибки. Затем новый активный сервер говорит: «reconnect failed failed: connection unknown for id = XY»

Это происходит, только если на моем клиенте есть открытое соединение. Но это то, что я ожидаю, соединение должно также переключиться на новый активный сервер. И, как я уже сказал, иногда это работает, а иногда и нет.

Когда я регистрируюсь для EMS-Exceptions в моем клиенте, я получаю сообщение об ошибке: «Невозможно прочитать данные из транспортного соединения: существующее соединение было принудительно закрыто удаленным хостом».

StackTrace: на System.Net.Sockets.NetworkStream.Read (байты [] буфер, Int32 смещения, Int32 размер) в TIBCO.EMS.LinkTcp._readEx (байты [] буфер, Int32 смещения, Int32 размера) в TIBCO.EMS.LinkTcp._ReadWireMsg() в TIBCO.EMS.LinkTcp.LinkReader.Work()

Прямо сейчас у меня нет больше понятия, что я мог бы сделать. Может быть, кто-то может помочь мне понять, в чем проблема. Заранее спасибо

UPDATE: Поздний обновление здесь: Даже если я получаю ошибку «переподключение не удалось» он работает, как ожидалось. Второй сервер возьмет верх.

Answer 1

Вот что происходит ... Сервер EMS отслеживает активные клиентские соединения, которые он имеет, и сохраняет информацию об этих соединениях в файле хранилища meta.db. При отказоустойчивом отказе новый первичный экземпляр EMS способен восстанавливать клиентские соединения, когда клиенты повторно соединяются, сопоставляя информацию, которую клиент предоставляет с информацией, хранящейся в файле хранилища meta.db.

Существует момент, когда EMS очищает клиентские соединения, которые не были повторно подключены. Это время определяется параметром ft_reconnect_timeout в файле конфигурации tibemsd.conf. Значение по умолчанию для этого параметра конфигурации составляет 60 секунд. В зависимости от настроек ведения журнала, когда EMS очищает «истекшие» соединения, вы можете увидеть mssage, указывающий, что он «очистил» клиентское соединение в ваших журналах EMS.

Бывают случаи, когда клиент в конце концов пытается восстановить соединение после того, как сервер EMS уже очистил «истекшее» соединение. Это может произойти в случае, если сетевой раздел не позволяет клиенту успешно переподключиться к серверу EMS до тех пор, пока сервер EMS не очистит соединение. Когда это произойдет, вы увидите сообщение «Повторное подключение: сообщение неизвестно ...».

Когда клиент не может «повторно подключиться» из-за этой ошибки, он просто пытается подключиться как «новое» соединение. Это работает, и он может продолжать обработку.

Answer 2

Это происходит, когда вы используете FT на стороне клиента, а не FT уровня сервера, по крайней мере, в нашем случае, когда мы столкнулись с этой проблемой, которая была основной причиной.

Если вы используете серверы ems с сервером FT URL1: порт, server2: port, но серверы не были действительно в режиме FT, когда соединение переключается между этими двумя серверами, у вас будет эта проблема как соединение перемещается на другой сервер, но существующее соединение на поврежденном сервере не может быть уничтожено или приобретено новым активным сервером из-за некогерентной настройки FT.

В настоящей настройке FT на стороне сервера активный сервер автоматически предполагает, что эти подключения будут активными и будут продолжать обслуживать их. Проверьте конфигурацию на уровне сервера.

Для нас обеспечение уровня сервера FT помогло решить эту проблему.