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

Reply via email to