Этот пост больше для меня и всех участников ActiveMQ, которые могут быть заинтересованы в том, как сетевые соединители работают для ActiveMQ. Недавно я потратил некоторое время на просмотр кода и подумал, что было бы неплохо составить несколько быстрых диаграмм, которые помогут мне запомнить то, что я узнал, и помогут определить, где отлаживаться в будущем, если возникнут проблемы, которые я исследую. Если я ошибаюсь и вы хотите добавить пояснения, пожалуйста, сделайте это в комментариях.
Сначала вы настраиваете свои сетевые соединители, настраивая их в файле конфигурации ActiveMQ. Эта конфигурация сопоставляется с соответствующими компонентами ActiveMQ с использованием библиотеки xbean, для которой у меня есть отдельный пост в блоге, который объясняет, как именно это делается. Чтобы указать сетевые соединители, добавьте элемент
<networkConnectors/> в свой файл конфигурации и добавьте <networkConnector/> , <multicastNetworkConnector/> или <ldapNetworkConnector/> . Эти три различных типа сетевых соединителей могут использоваться для создания сети посредников, где <networkConnector/> является наиболее распространенным. Вот как эти три сопоставляются с классами Java: <networkConnector/> сопоставляется с org.apache.activemq.network.DiscoveryNetworkConnector <multicastNetworkConnector/> сопоставляется с org.apache.activemq.network.MulticastNetworkConnector <ldapNetworkConnector/> сопоставляется с org.apache.activemq.network.LdapNetworkConnector Каждый из них наследуется от
org.apache.activemq.network.NetworkConnector как показано на этой диаграмме: 
Поэтому, когда у вас есть такая конфигурация:
|
1
|
<networkConnector uri="static://(tcp://localhost:61626,tcp://localhost:61627)" /> |
новый DiscoverNetworkConnector будет настроен, создан и добавлен в качестве коннектора к BrokerService (который является основным классом для обработки многих деталей брокера ActiveMQ). Во время сборки DiscoverNetworkConnector из конфигурации указанный вами URI используется для создания DiscoveryAgent. Агент обнаружения отвечает за сборку соединения и обработку событий отработки отказа, которые упакованы как DiscoverEvents. Определение того, какой DiscoverAgent выбран, зависит от DiscoverAgentFactory и указанного URI. В случае «статического» используется агент SimpleDiscoverAgent. Каждый URI в списке возможных URI обрабатывается по-разному и ему присваивается собственный транспорт (подробнее об этом через секунду). Это означает, что для каждого URI, который вы перечисляете, будет установлен новый сокет, и посредник попытается установить сетевой соединитель для каждого из сокетов. Вы можете быть удивлены, как лучше всего реализовать отказоустойчивость? В случае, описанном выше, у вас будет несколько подключений, и если одно из этих подключений будет к ведомому, который не прослушивает, вы увидите, что соединение не установлено, и агент обнаружения пытается установить соединение снова. Это может продолжаться бесконечно, что потребляет ресурсы. Другой подход заключается в использовании только одного URI для агента статического обнаружения, который использует логику failover ():
|
1
|
<networkConnector uri="static:failover:(tcp://localhost:61626,tcp://localhost:61627)" /> |
В этом случае будет создан только один транспорт, и логика аварийного переключения обернет его и узнает об обоих URI. Если один из них недоступен, он не будет повторять попытки без необходимости. Вместо этого он будет подключаться к тому, который может, и повторно подключаться только к URL-адресу аварийного переключения, если текущее подключение обрывается. Обратите внимание, что в этом подходе была ошибка до версии ActiveMQ 5.5.1.-fuse-00-06.
Агент обнаружения отвечает за создание моста, но он делегирует эту ответственность DiscoverListener. В приведенном выше примере интерфейс DiscoverListener реализуется методом DiscoverNetworkConnector.onServiceAdd ().
Чтобы установить мост, транспорт открывается как для локального посредника (с использованием виртуальной машины), так и для удаленного посредника (с использованием указанного протокола, в данном случае TCP). После создания локального и удаленного транспорта мост можно собрать в методе DiscoverNetworkConnector.createBridge (…). Этот метод снова использует шаблон Factory, чтобы найти, какой мост использовать.
Возможные реализации моста показаны ниже:
По умолчанию, если для WireitSubscription = true, используется DurableConduitBridge. Подписки на каналы устанавливают единый поток сообщений для удаленного посредника, чтобы уменьшить дубликаты, которые могут возникать, когда в удаленных темах есть несколько потребителей. По умолчанию это прекрасно работает, но если вы хотите распределить нагрузку по сообщениям для всех потребителей, вам нужно установить для подписок на каналы значение false (см. Документацию для подписок на каналы в документации FuseSource на Fuse Message Broker ). При значении false используется DemandForwardingBridge. После того как мост собран, он настраивается в методе NetworkConnector.configureBridge (…).
Когда все собрано и настроено на мосту, оно запускается. После запуска он отправляет объекты Command посредника удаленному посреднику, чтобы идентифицировать себя, настроить сеанс и запросить информацию о нем от потребителя. Это в методе суперкласса DemandForwardingBridgeSupport.startRemoteBridge (), как видно из диаграммы.
Если вы отлаживаете ошибки с помощью сетевых разъемов, надеюсь, это поможет определить возможные места, где могут возникать ошибки.
Ссылка: изнутри кода: ActiveMQ Network Connectors от нашего партнера JCG Кристиана Поста в блоге