Hi, Are there any queues where there is no movement vs. ones where there is a steady shift in enqueued/dequeued counts? Or any topic where there are one or more consumers and any pending messages to be dequeued?
I wouldn't typically expect a memory limit on a queue to cause a consumer to not be able to read messages. I would expect it to prevent a producer from writing a new message. Depending on our version of ActiveMQ I suppose it might be a situation where a common socket is deadlocked due to the broker throttling a shared connection because the producer keeps trying to send messages: http://activemq.apache.org/producer-flow-control.html When you say you are out of memory, are you saying your JVM has actually run completely out of memory? If you can browse the webconsole I'd be surprised if that were the case. But if it is, you can check your configuration to see how it's set up to manage memory queue limits. For example, on my setup I have this: <!-- http://activemq.apache.org/producer-flow-control.html --> <systemUsage> <systemUsage sendFailIfNoSpaceAfterTimeout="3000"> <memoryUsage> <memoryUsage percentOfJvmHeap="70"/> </memoryUsage> <storeUsage> <storeUsage limit="12 gb"/> </storeUsage> <tempUsage> <tempUsage limit="4 gb"/> </tempUsage> </systemUsage> </systemUsage> This attempts to ensure that the JVM will always have at least ~30% of its MX memory limit available for operations unrelated to buffering messages. The sendFailIfNoSpaceAfterTimeout attribute tells activemq to throw an exception to producers if a producer tries to write a message and it is blocked for more than 3 seconds waiting for memory on the queue to become available. But that's a dangerous attribute to add if your producers aren't coded up to handle the situation (of course, if you're reached the point where you are manually purging messages then perhaps it'd be fine to enable to see what producers start failing). In addition, by default I cap the queue and topic sizes unless they are specifically called out as needing to be larger: <!-- http://activemq.apache.org/producer-flow-control.html --> <!-- http://activemq.apache.org/message-cursors.html --> <destinationPolicy> <policyMap> <policyEntries> <policyEntry topic=">" memoryLimit="1mb"> </policyEntry> <policyEntry queue=">" memoryLimit="1mb" optimizedDispatch="true"> </policyEntry> <policyEntry queue="AL.>" memoryLimit="100mb" optimizedDispatch="true"> </policyEntry> </policyEntries> </policyMap> </destinationPolicy> I don't think you need to manually delete all the KahaDB logs to clear space, I think just using the Purge option on a queue should clear it of pending messages. If you can't find any other means of tracking down the bad queue, cycling through each queue one at a time and purging it could show you where the bottleneck is. Jim