Уведомление TIBCO EMS издателю в случае отказа подписчика

Question

Я пытаюсь найти ответ о том, как уведомить издателя EMS в случае сбоя подписчика.В случае Publisher-> EMS server-> Subscriber, если подписчик отказывает, мне нужно сообщить Publisher, чтобы он предпринял корректирующие действия. Меня не беспокоит долговечность / PERSIETENCE, мое значение имеет время.В Торговых системах, если я отправляю рыночный ордер подписчику, который, в свою очередь, отправляет его на биржу, если он выходит из строя, мне нужно, чтобы мой издатель опубликовал сообщения на другую тему другому Sunscriber (другой бирже).Любые идеи приветствуются.

Answer 1

Библиотека tibjmsadmin.jar содержит методы для обнаружения отключения абонентов.Проще, чем писать код, вы можете:

• , если у вас есть Hawk, использовать tibjmsadmin.hma, чтобы написать правило Hawk в случае отключения абонента, или
• прослушивание на монитореtopic $ sys.monitor.connection.disconnect - в тексте сообщения указывается, какой абонент отключен.

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

EMS знает, когда подписчики подключены или нет, и вы должны воспользоваться этим.

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

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

См. Руководство EMS для получения более подробной информации по всем этим темам.

Answer 2

Не уверен, что если у вас есть доступ, вы можете попробовать просмотреть ReceiverCount или ConsumerCount в QueueInfo или TopicInfo - я считаю, что вам нужен пакет tibjms.admin. Может быть, вы можете запросить это, прежде чем публиковать, а затем выборочно публиковать? Не уверен, что накладные расходы.

Из-за природы JMS, AFAIK никакие транзакции не сообщаются (если вы не используете транзакцию XA - со всеми этими издержками) или подтверждения будут распространяться через брокера EMS. I.e.acks всегда между издателем и брокером и потребителем и брокером.

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

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

Я действительно не вижу преимущества разъединенной шины обмена сообщениями в вашем потоке заказов ... для меня нет смысла ..