5
我目前正在調查我的代理網絡中的內存問題。 根據JConsole，當代理開始阻止消息時，ActiveMQ.Advisory.TempQueue佔用配置內存的99％。經紀人網絡充斥着未消費的ActiveMQ.Advisory.TempQueue消息
有關配置
預設配置在大多數情況下的一些細節。一個開放的踏板+ nio連接器，一個開放的openwire連接器。所有經紀人形成一個超立方體（與其他經紀人的一個在途連接（更容易自動生成））。沒有流量控制。
問題的詳細說明
的Web控制檯顯示像1974234排隊和45345在30名消費者出隊的消息（6個經紀人，一個消費者，其餘的是使用java連接器的客戶端）。據我所知，出列數不應小於：入列的*消費者。所以在我的情況下，大量的建議不會被消耗並開始填充我的臨時消息空間。 （目前我配置了幾個GB作爲臨時空間）
由於沒有客戶端主動使用臨時隊列，我覺得這很奇怪。看看臨時隊列後，我更加困惑。大多數消息是這樣的（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 = [email protected], 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}
看到這些消息後，我有幾個問題：
- 我是否理解正確的是，消息的來源是跺腳連接？
- 如果是，stomp連接如何創建臨時隊列？
- 是否有一個簡單的理由，爲什麼諮詢不被消費？
目前我通過停用網絡連接器上的bridgeTempDestinations屬性推遲了這個問題。通過這種方式，消息不會被傳播，它們會更慢地填充臨時空間。如果我無法修復這些消息的來源，我至少會阻止他們填滿商店：
- 我可以在某段時間後放棄這些未消費的消息嗎？
- 這有什麼後果？
更新：我更多地監視了我的集羣並發現消息已被消耗。它們被排隊和分派，但消費者（其他羣集節點與使用activemq lib的java消費者一樣多）無法確認消息。所以他們留在派發的消息隊列中，這個隊列增長和增長。
你真的有在他們的諮詢郵件隊列？或者他們是主題？如果他們是排隊的 - 你是否有特定的消費者？ – Paul
它們是主題，但代理網絡節點和java資源適配器在默認情況下在TempQueue目標上偵聽。 – Laures
嗨@Laures，我有類似的問題。 1.您是如何設法監控這種情況的？ 2.你最終是如何解決的？ –