Восстановление соединения TIBCO EMS для C # (TIBCO.EMS.dll) - PullRequest
12 голосов
/ 09 октября 2008

У нас есть решение TIBCO EMS, которое использует встроенный отказоустойчивый сервер в среде с 2-4 серверами. Если администраторы TIBCO осуществляют отработку отказа с одного сервера EMS на другой, предполагается, что соединения автоматически передаются на новый сервер на уровне обслуживания EMS. Для наших приложений C #, использующих службу EMS, этого не происходит - наши пользовательские подключения не передаются на новый сервер после отработки отказа, и мы не уверены, почему.

Соединение нашего приложения с EMS только при запуске, поэтому, если администраторы TIBCO переключаются после запуска нашего приложения, им необходимо перезапустить приложение, чтобы повторно подключиться к новому серверу (наше соединение EMS использует строку сервера, включающую все рабочие серверы EMS - если первая попытка не удалась, она перемещается на следующий сервер в строке и пытается снова).

Я ищу автоматический подход, который будет периодически пытаться повторно подключиться к EMS, если он обнаружит, что соединение не работает, но я не уверен, как лучше это сделать.

Есть идеи? Мы используем TIBCO.EMS.dll версии 4.4.2 и .Net 2.x (приложение SmartClient)

Любая помощь будет оценена.

Ответы [ 3 ]

8 голосов
/ 24 октября 2008

Прежде всего, да, я отвечаю на свой вопрос. Однако важно отметить, что без ajmastrean я был бы никуда. большое спасибо!

ONE: ConnectionFactory.SetReconnAttemptCount, SetReconnAttemptDelay, SetReconnAttemptTimeout должны быть установлены соответствующим образом. Я думаю, что значения по умолчанию повторяются слишком быстро (порядка 1/2 секунды между повторными попытками). Наши серверы EMS могут долго переходить на аварийное переключение из-за сетевого хранилища и т. Д., Поэтому 5 повторных попыток с интервалом в 1/2 секунды еще далеко не достаточно.

TWO: Я считаю, что важно активировать тактовые импульсы клиент-сервер и сервер-клиент. Не удалось проверить, но без них клиент может не получить уведомление о том, что сервер находится в автономном режиме или переключается в режим отработки отказа. Это, конечно, настройка сервера для EMS.

ТРЕТИЙ: Вы можете наблюдать за событием аварийного переключения, установив Tibems.SetExceptionOnFTSwitch (true); а затем подключить обработчик события исключения. В среде с одним сервером вы увидите сообщение «Соединение разорвано». Однако, если вы находитесь в отказоустойчивой многосерверной среде, вы увидите следующее: «Соединение выполнило отказоустойчивое переключение на». Вам строго не нужно это уведомление, но оно может быть полезно (особенно при тестировании).

ЧЕТВЕРТЫЙ: Очевидно, что это не ясно в документации EMS, переподключение соединения НЕ будет работать в среде с одним сервером. Вы должны быть в многосерверной, отказоустойчивой среде. Однако есть хитрость. Вы можете поместить один и тот же сервер в список подключений дважды - странно, я знаю, но он работает и позволяет работать встроенной логике повторного подключения.

некоторый код:

private void initEMS()
{
    Tibems.SetExceptionOnFTSwitch(true);
    _ConnectionFactory = new TIBCO.EMS.TopicConnectionFactory(<server>);
    _ConnectionFactory.SetReconnAttemptCount(30);       // 30retries
    _ConnectionFactory.SetReconnAttemptDelay(120000);   // 2minutes
    _ConnectionFactory.SetReconnAttemptTimeout(2000);   // 2seconds
_Connection = _ConnectionFactory.CreateTopicConnectionM(<username>, <password>);
    _Connection.ExceptionHandler += new EMSExceptionHandler(_Connection_ExceptionHandler);
}
private void _Connection_ExceptionHandler(object sender, EMSExceptionEventArgs args)
{
    EMSException e = args.Exception;
    // args.Exception = "Connection has been terminated" -- single server failure
    // args.Exception = "Connection has performed fault-tolerant switch to <server url>" -- fault-tolerant multi-server
    MessageBox.Show(e.ToString());
}
6 голосов
/ 17 октября 2008

Этот пост должен обобщить мои текущие комментарии и объяснить мой подход более подробно ...

Типы TIBCO 'ConnectionFactory' и 'Connection' - это тяжелые, поточно-ориентированные типы. TIBCO предлагает вам использовать one ConnectionFactory (для каждой фабрики, настроенной на сервере) и one Connection на фабрику.

Сервер также , по-видимому, отвечает за аварийное переключение и повторное подключение 'Connection' на месте, поэтому давайте подтвердим, что он выполняет свою работу, а затем используем эту функцию.

Создание решения на стороне клиента будет несколько более сложным, чем решение проблемы с настройкой сервера или клиента. Все сеансы, которые вы создали из неуспешного соединения, необходимо создать заново (не говоря уже о производителях, потребителях и местах назначения). Нет методов «переподключиться» или «обновить» ни для одного типа. Сеансы также не поддерживают ссылку на родительское соединение.

Вам придется управлять поиском объектов подключения / сеанса и сходить с ума, переинициализируя всех! или реализовать какой-либо обработчик событий сбоя сеанса, который может получить новое соединение и повторно подключить их.

Итак, давайте сейчас покопаемся и посмотрим, настроен ли клиент на получение уведомления об отказоустойчивости (руководство пользователя tib ems, стр. 292). И убедитесь, что возбужденное исключение перехвачено, содержит URL-адрес аварийного переключения и обрабатывается правильно.

1 голос
/ 17 октября 2008

Клиентские приложения могут получать уведомления об отказе, задав свойство системы tibco.tibjms.ft.switch.exception

Может, библиотеке это нужно?

...