Невидимый потребитель ActiveMQ Artemis в очереди моста $.artemis.internal.sf

Иногда внутренняя очередь $.artemis.internal.sf... накапливается сообщениями. Я не могу воспроизвести проблему, поэтому пытаюсь собрать как можно больше информации.

В веб-консоли ActiveMQ Artemis, когда я нажимаю на счетчик 1 потребитель на странице очереди: следующая страница не показывает ни одного потребителя в этой очереди:

Это ошибка или я что-то упускаю?

Как я могу проверить, действительно ли есть потребитель в очереди $.artemis.internal.sf и что это за потребитель?

Журналы показывают, что мост успешно подключен:

2022-11-09 23:11:33,088 INFO  [org.apache.activemq.artemis.core.server] AMQ221027: Bridge ClusterConnectionBridge@57073510 [name=$.artemis.internal.sf.my-cluster.aa352e1f-5708-11ed-a36c-00163ec45fe5, queue=QueueImpl[name=$.artemis.internal.sf.my-cluster.aa352e1f-5708-11ed-a36c-00163ec45fe5, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::name=masterA], temp=false]@580c8c14 targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@57073510 [name=$.artemis.internal.sf.my-cluster.aa352e1f-5708-11ed-a36c-00163ec45fe5,queue=QueueImpl[name=$.artemis.internal.sf.my-cluster.aa352e1f-5708-11ed-a36c-00163ec45fe5, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::name=masterA], temp=false]@580c8c14 targetConnector=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=masterB, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=61626&host=127-0-0-3], discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1876390738[nodeUUID=a8dd3f57-5708-11ed-aef9-a8a15976b7bf, connector=TransportConfiguration(name=masterA, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=61616&host=127-0-0-1, address=, server=ActiveMQServerImpl::name=masterA])) [initialConnectors=[TransportConfiguration(name=masterB, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?port=61626&host=127-0-0-3], discoveryGroupConfiguration=null]] is connected

Версия ActiveMQ Artemis — 2.26.0 (то же самое с 2.22.0).

Я знаю, что эта очередь используется для соединения двух активных экземпляров в кластере и управляется элементом конфигурации cluster-connection в broker.xml.

Я использую статическую конфигурацию кластера (на основе TCP, без группы обнаружения, без широковещательной группы).

Идентификатор узла masterA: a8dd3f57-5708-11ed-aef9-a8a15976b7bf

Идентификатор узла masterB: aa352e1f-5708-11ed-a36c-00163ec45fe5

Я могу добавить broker.xml как masterA, так и masterB, если это уместно/необходимо.

Любая помощь будет высоко ценится!

ОБНОВЛЕНИЕ: cluster-connection для masterA и masterB соответственно следующие:

кластерное соединение для masterA

<cluster-connections>
    <cluster-connection name = "my-cluster">
        <connector-ref>masterA</connector-ref>
        <message-load-balancing>ON_DEMAND</message-load-balancing>
        <max-hops>2</max-hops>
        <static-connectors>
            <connector-ref>masterA</connector-ref>
            <connector-ref>slaveA</connector-ref>
            <connector-ref>masterB</connector-ref>
            <connector-ref>slaveB</connector-ref>
        </static-connectors>
    </cluster-connection>
</cluster-connections>

кластерное соединение для masterB:

<cluster-connections>
    <cluster-connection name = "my-cluster">
        <connector-ref>masterB</connector-ref>
        <message-load-balancing>ON_DEMAND</message-load-balancing>
        <max-hops>2</max-hops>
        <static-connectors>
            <connector-ref>masterA</connector-ref>
            <connector-ref>slaveA</connector-ref>
            <connector-ref>masterB</connector-ref>
            <connector-ref>slaveB</connector-ref>
        </static-connectors>
    </cluster-connection>
</cluster-connections>

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

will 10.11.2022 00:07

нет большого сообщения в наших материалах. Я думаю, что 5k самое большее, и это редкий случай.

will 10.11.2022 00:09

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

will 10.11.2022 00:13
здесь вопрос по раскачке с более подробной информацией
will 10.11.2022 11:45

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

will 10.11.2022 13:09
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
5
56
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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

Понятно. Можно ли добавить параметр подключения к кластеру, например clientId? Это помогло бы идентифицировать потребителя ИМО. Кроме того, я, возможно, пропустил это из документа, но, возможно, подчеркну, что то, что вы только что объяснили, может быть полезным.

will 15.11.2022 14:35

Другие вопросы по теме