我目前正在调查我的经纪商网络中的内存问题。
根据 JConsole 的说法，当代理开始阻止消息时，ActiveMQ.Advisory.TempQueue 占用了 99% 的配置内存。
有关配置的一些细节
大部分情况下都是默认配置。一个开放的 stomp+nio 连接器，一个开放的 openwire 连接器。所有经纪人形成一个超立方体（与每个其他经纪人的一个途中连接（更容易自动生成））。没有流量控制。
问题详情
Web 控制台在 30 个消费者（6 个代理、1 个消费者，其余是使用 java 连接器的客户端）处显示类似 1974234 条入队消息和 45345 条出队消息。据我所知，出队计数应该不小于：enqueued*consumers。因此，就我而言，大量建议不会被消耗，并开始填充我的临时消息空间。 （目前我配置了几个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 = 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}
看到这些消息后我有几个问题：
- 我是否正确理解消息的来源是 stomp 连接？
- 如果是，stomp 连接如何创建临时队列？
- 这些建议未被采纳是否有一个简单的原因？
目前，我通过停用网络连接器上的bridgeTempDestinations 属性来推迟问题的解决。这样消息就不会传播，并且它们填充临时空间的速度会慢得多。如果我无法修复这些消息的来源，我至少想阻止它们填充商店：
- 我可以在一段时间后删除这些未使用的消息吗？
- 这会产生什么后果？
更新：我对集群进行了更多监控，发现消息已被消耗。它们已排队并分派，但消费者（与使用 activemq 库的 java 消费者一样多的其他集群节点）无法确认消息。因此它们保留在已调度的消息队列中，并且该队列不断增长。
