Сеть брокеров ActiveMQ с длительными темами подписки

Question

У меня здесь небольшая проблема с моим образцом JMS.

У меня есть два брокера (A, B) на двух машинах, которые связаны через сетевой разъем. Идея заключается в том, что производитель может отправлять любому брокеру, и потребитель может слушать любого брокера, а тема для отправки/получения доступна во всем мире.

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

Каждый брокер «A» и «B» подключен к абоненту. Производитель отправляет «A». Брокер «B» перезапускается. Клиент «B» регистрирует потерю соединения и переключает на «A». «B» снова появляется, и поскольку он сам зарегистрировался как долговечный подписчик на «А», он получает сообщение. У этого нет активного долговечного подписчика (теперь «А» имеет три, включая «В»), и накапливается до тех пор, пока не достигнет пределов своего соединения.

Является ли моя конфигурация неправильной? Возможно ли, что я намеревался?

Cheers, Kai

Answer 1

1. Используете конфигурации ведущий-ведомый?
2. Почему вы хотите, чтобы оба брокера одновременно подключили клиентов?

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

Чтобы оба узла (ведущий и ведомый) всегда вам нужны точные долговечные данные
, чтобы сохранить ваши сообщения в одном и том же месте, доступном для обоих узлов. Это может быть адаптер JDBC, подключенный к одному экземпляру базы данных (возможно, за кластером), или он может быть NAS с общей сетевой папкой для KahaDB.