В настоящее время я изучаю проблему с памятью в сети моего брокера.
Согласно JConsole, ActiveMQ.Advisory.TempQueue занимает 99% сконфигурированной памяти, когда брокер начинает блокировать сообщения.
Несколько подробностей о конфигурации
Конфигурация по умолчанию для большей части. Один открытый разъем Stomp + Nio, один открытый разъем OpenWire. Все брокеры образуют гиперкуб (одно соединение в пути с любым другим брокером (проще генерировать автоматически)). Нет управления потоком.
Детали проблемы
Веб-консоль показывает что-то вроде сообщений в очереди 1974234 и 45345 в очереди у 30 потребителей (6 брокеров, один потребитель, а остальные - клиенты, использующие Java-коннектор). Насколько я знаю, счетчик очереди должен быть не намного меньше, чем: поставленные в очередь * потребители. поэтому в моем случае большая куча рекомендаций не расходуется и начинает заполнять мое временное пространство сообщений. (в настоящее время я настроил несколько ГБ в качестве временного пространства)
Поскольку ни один клиент активно не использует временные очереди, я нахожу это очень странным. Посмотрев на временную очередь, я еще больше запутался. Большинство сообщений выглядят так (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}
После просмотра этих сообщений у меня возникло несколько вопросов:
- Правильно ли я понимаю, что источником сообщения является соединение с помпой?
- Если да, как соединение с помпой может создавать временные очереди?
- Есть ли простая причина, по которой рекомендации не расходуются?
В настоящее время я как бы отложил проблему, деактивировав свойство bridgeTempDestination на сетевых соединителях. таким образом сообщения не распространяются, и они заполняют временное пространство намного медленнее. Если я не могу исправить источник этих сообщений, я бы хотя бы хотел помешать им заполнить магазин:
- Можно ли отбросить эти неиспользованные сообщения через определенное время?
- какие последствия это может иметь?
ОБНОВЛЕНИЕ: я еще немного проверил свой кластер и обнаружил, что сообщения используются. Они поставлены в очередь и отправлены, но потребители (другие узлы кластера, такие же как Java-потребители, использующие lib activemq) не могут подтвердить сообщения. поэтому они остаются в очереди отправленных сообщений, и эта очередь растет и растет.