activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject Re: Global memory limit for all queues / fileQueueCursor question
Date Wed, 18 Aug 2010 01:40:18 GMT
On Tue, Aug 17, 2010 at 2:36 PM, Martin C. <> wrote:
> Hi,
> thanks for the very fast answer.
> On Tue, Aug 17, 2010 at 8:48 PM, Bruce Snyder <> wrote:
>>>    <systemUsage>
>>>      <systemUsage sendFailIfNoSpace="true">
>>>        <memoryUsage>
>>>          <memoryUsage limit="256 mb" />
>>>        </memoryUsage>
>>>      </systemUsage>
>>>    </systemUsage>
>> The memoryUsage above should limit the entire broker to 256mb of
>> memory. I just tested this by lowering the memoryUsage limit to 15mb
>> and maxed that out pretty easily by flooding a queue with messages and
>> not consuming them very fast.
> Thanks for the verification, this is what I was hoping.
>> However, if you are sending non-persistent messages, then you need to
>> set the tempUsage element within the systemUsage element. The
>> tempUsage element  governs the amount of disk space that is allowed to
>> be used to hold non-persistent messages.
> Ok, I assumed that the tempUsage element might be necessary here as
> well. Do I have to include a <store> section in the <tempUsage>
> element or will it pick up the default message store if I don't.
> That's something I couldn't really find out from documentation.

The <tempUsage> element and the <storeUsage> elements are separate
from one another. See the default activemq.xml for an example.

If you are using the AMQ persistence or the KahaDB persistence, you
will need the <storeUsage> to specify how much disk space to use for
persistent messages. The producer flow control URL below provides the
full info.

>> I also notice above that you have disabled producer flow control. By
>> disabling this setting, you have disallowed the broker from slowing
>> down producers who may be flooding the broker.
> Using "sendFailIfNoSpace" (in systemUsage), I expected the producers
> will rather fail fast instead of blocking, as I can deal with failure
> on my producers more easily than with a "hung" producer.

Read up on producer flow control so that you understand the whole story:

>> Also, what version of ActiveMQ are you using?
> I'm currently still on a 5.3.1-fuse release for a backport of an XA
> memory leak fix (AMQ-2556), but hope to upgrade the system to 5.4 now
> that it is out.
> Best regards,
> Martin

perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"

ActiveMQ in Action:

View raw message