Блог

В настоящее время я расследую проблему с памятью в моей сети брокера. Согласно JConsole, ActiveMQ.Advisory.Временная очередь занимает 99% настроенной памяти, когда брокер начинает блокировать сообщения.

Несколько подробностей о конфигурации

Конфигурация по умолчанию по большей части. Один открытый разъем stomp nio, один открытый разъем openwire. Все брокеры образуют гиперкуб (одно промежуточное соединение с любым другим брокером (проще автоматически генерировать)). Нет управления потоком.

Подробности проблемы

Веб-консоль показывает что-то вроде 1974234 сообщений в очереди и 45345 сообщений из очереди у 30 потребителей (6 брокеров, один потребитель, а остальные — клиенты, использующие java connector). Насколько я знаю, количество удалений из очереди должно быть не намного меньше, чем: поставленные в очередь * потребители. итак, в моем случае большая куча рекомендаций не используется и начинает заполнять мое временное пространство сообщений. (в настоящее время я настроил несколько ГБ в качестве временного пространства)

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

 ActiveMQMessage {commandId = 0, responseRequired = false, messageId = ID:srv007210-36808-1318839718378-1:1:0:0:203650, originalDestination = null, originalTransactionId = null, producerId = ID:srv007210-36808-1318839718378-1:1:0:0, destination = topic://ActiveMQ.Advisory.TempQueue, transactionId = null, expiration = 0, timestamp = 0, arrival = 0, brokerInTime = 1318840153501, brokerOutTime = 1318840153501, correlationId = null, replyTo = null, persistent = false, type = Advisory, priority = 0, groupID = null, groupSequence = 0, targetConsumerId = null, compressed = false, userID = null, content = null, marshalledProperties = org.apache.activemq.util.ByteSequence@45290155, dataStructure = DestinationInfo {commandId = 0, responseRequired = false, connectionId = ID:srv007210-36808-1318839718378-2:2, destination = temp-queue://ID:srv007211-47019-1318835590753-11:9:1, operationType = 1, timeout = 0, brokerPath = null}, redeliveryCounter = 0, size = 0, properties = {originBrokerName=broker.coremq-behaviortracking-675-mq-01-master, originBrokerId=ID:srv007210-36808-1318839718378-0:1, originBrokerURL=stomp://srv007210:61612}, readOnlyProperties = true, readOnlyBody = true, droppable = false}
  

После просмотра этих сообщений у меня возникло несколько вопросов:

1. Правильно ли я понимаю, что источником сообщения является соединение stomp?
2. Если да, то как соединение stomp может создавать временные очереди?
3. Есть ли простая причина, по которой рекомендации не используются?

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

1. Могу ли я удалить эти неиспользованные сообщения через определенное время?
2. какие последствия это может иметь?

ОБНОВЛЕНИЕ: я еще немного проследил за своим кластером и обнаружил, что сообщения используются. Они поставлены в очередь и отправлены, но потребители (другие узлы кластера, а также пользователи Java, использующие activemq lib) не могут подтвердить сообщения. таким образом, они остаются в очереди отправленных сообщений, и эта очередь растет и растет.

Это старая тема, но на случай, если кто-то столкнется с такой же проблемой, вы можете захотеть ознакомиться с этим сообщением: http://forum.spring.io/forum/spring-projects/integration/111989-jms-outbound-gateway-temporary-queues-never-deleted

Проблема в этой ссылке звучит аналогично, т. Е. Временные очереди выдают большое количество рекомендательных сообщений. В моем случае мы использовали временные очереди для реализации синхронного обмена сообщениями с запросами / ответами, но из-за большого количества рекомендательных сообщений ActiveMQ проводил большую часть своего времени в GC и в конечном итоге выдал исключение с превышением лимита накладных расходов GC. Это было в версии 5.11.1. Несмотря на то, что мы закрыли соединение, сеанс, производителя, потребителя, временная очередь не была бы GC’d и продолжала бы получать рекомендательные сообщения.

Решение состояло в явном удалении временных очередей при очистке других ресурсов (см.https://docs.oracle.com/javaee/7/api/javax/jms/TemporaryQueue.html)

Если вы не используете этот раздел рекомендаций — вы можете отключить его, как это предлагается на http://activemq.2283324.n4.nabble.com/How-to-disable-advisory-for-gt-topic-ActiveMQ-Advisory-TempQueue-td2356134.html

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