ActiveMQ Artemis $.artemis.internal.sf иногда создает сообщения

В случайное время очередь моста кластера $.artemis.internal.sf накапливает сообщения, как будто мост завис. Другие очереди с удовольствием принимают сообщения и потребляют их, как и ожидалось, даже под нагрузкой.

В производстве установка следующая:

• Версия ActiveMQ Artemis — 2.22.0, работающая на Java 11 (не наблюдается чрезмерного GC или нет во время сборки).
• 2 «уровня» кластеров, скажем, один для «поверхности» и один для «глубокого» материала. 2 виртуальные машины vmware для каждого уровня в одном и том же теге безопасности / vlan (у меня нет доступа к этому, и изменить его может быть невозможно).
• «Поверхностные» виртуальные машины — это artm и arts, «глубокие» виртуальные машины — это artim и artis.
• Каждый из этих уровней содержит 3 кластера (например, кластер-1, кластер-2 и кластер-3, настоящие имеют разные имена, но я не могу их разглашать) с 2 ведущими и 2 подчиненными в каждом, сгруппированными в пары masterA с slaveA и masterB с slaveB (используя имя группы в ha-policy

artm has masterA-S1, masterA-S2, masterA-S3 and slaveB-S1, slaveB-S2, slaveB-S3
arts has masterB-S1, masterB-S2, masterB-S3 and slaveA-S1, slaveA-S2, slaveA-S3

artim has masterA-D1, masterA-D2, masterA-D3 and slaveB-D1, slaveB-D2, slaveB-D3
artis has masterB-D1, masterB-D2, masterB-D3 and slaveA-D1, slaveA-D2, slaveA-D3

• Порты адаптированы, чтобы избежать коллизий, и все работает хорошо.
• В «глубоких» кластерах у нас есть приложения, которые могут иметь только одного потребителя, поэтому мы используем перераспределение сообщений, поскольку мы точно не знаем, к какому из двух мастеров он будет подключаться (connectionFactories и providerUrl установлены нормально).
• Конфигурация 3 кластеров на данном уровне аналогична.

Соединения кластера следующие

мастерA-D1

<cluster-connections>
   <cluster-connection name = "cluster-D1">
      <connector-ref>connector-D1-master-a</connector-ref>
      <check-period>1000</check-period>
      <connection-ttl>20001</connection-ttl>
      <initial-connect-attempts>-1</initial-connect-attempts>
      <reconnect-attempts>1</reconnect-attempts>
      <use-duplicate-detection>true</use-duplicate-detection>
      <message-load-balancing>ON_DEMAND</message-load-balancing>
      <max-hops>1</max-hops>
      <notification-interval>2000</notification-interval>
      <notification-attempts>2</notification-attempts>
         <static-connectors>
            <connector-ref>connector-D1-slave-a</connector-ref>
            <connector-ref>connector-D1-master-b</connector-ref>
            <connector-ref>connector-D1-slave-b</connector-ref>
         </static-connectors>
   </cluster-connection>
</cluster-connections>

masterB-D1

<cluster-connections>
   <cluster-connection name = "cluster-D1">
      <connector-ref>connector-D1-master-b</connector-ref>
      <check-period>1000</check-period>
      <connection-ttl>20001</connection-ttl>
      <initial-connect-attempts>-1</initial-connect-attempts>
      <reconnect-attempts>1</reconnect-attempts>
      <use-duplicate-detection>true</use-duplicate-detection>
      <message-load-balancing>ON_DEMAND</message-load-balancing>
      <max-hops>1</max-hops>
      <notification-interval>2000</notification-interval>
      <notification-attempts>2</notification-attempts>
      <static-connectors>
         <connector-ref>connector-D1-slave-b</connector-ref>
         <connector-ref>connector-D1-master-a</connector-ref>
         <connector-ref>connector-D1-slave-a</connector-ref>
      </static-connectors>
   </cluster-connection>
</cluster-connections>

Уровень поверхности имеет в общей сложности около 400 очередей (любая передача) и около 450 для глубокого рычага (также любая передача).

Мост между masterA и masterB подключен правильно. Логи это подтверждают.

Ежедневно вся система обрабатывает около 8-9 миллионов сообщений.

Мы попытались зарегистрировать класс org.apache.activemq.artemis.core.server.cluster.impl.BridgeImpl в надежде увидеть "Bridge retrying connection # (что указывало бы на проблему с подключением и требовало увеличения количества попыток повторного подключения), но безуспешно.

Когда происходит наращивание, другие экземпляры по-прежнему ведут себя хорошо.

Мы просто устанавливаем повторные попытки подключения на -1 (неограниченное количество повторных попыток). Подождите и посмотрите, поможет ли это, но я сомневаюсь в этом.

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

Другой мост не настроен.

Наращивание не обязательно происходит ни при большой нагрузке, ни при большом времени безотказной работы. Мы видели наращивание с временем безотказной работы 7 дней, тогда как у нас есть другие экземпляры с временем безотказной работы 35+ дней без проблем и с таким же типом использования/трафика.

Мы не можем это воспроизвести. Вот почему я даю столько информации, сколько могу.

Я могу предоставить более подробную информацию, если требуется.

Я нашел это ТАКОЕ, но не уверен, что это связано. Хотя мы отправляем некоторые большие сообщения, это не то, что мы отправляем чаще всего, но я должен предположить, что с учетом нашей настройки мост может пересылать большие сообщения. У нас есть максимум 50 больших сообщений в день по всей системе.