Hi Gary,
I checked out your test case and seeing that that worked fine set out
to figure out why my test case didn't.
As it turns out it is because of my <tempUsage>:
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage limit="100 mb"/>
</memoryUsage>
<storeUsage>
<storeUsage limit="20 gb" name="store"/>
</storeUsage>
<tempUsage>
<tempUsage limit="100 mb"/>
</tempUsage>
</systemUsage>
</systemUsage>
When I comment out the <tempUsage> everything works fine.
Your test case has the same behaviour, if you also set:
brokerService.getSystemUsage().getTempUsage().setLimit(10 *
1024 * 1024);
When set the broker will just freeze after some number of messages,
and using JMX/JConsole the queue now doesn't render its attributes,
you can't connect a consumer etc.
Is that expected behaviour?
I also found that using my current configuration I don't seem to have
to tweak my cursorMemoryHighWaterMark at all, everything seems to work
fine without it for my settings (queue memoryLimit=10mb,
producerFlowControl=true, memoryUsage limit=100mb, storeUsage
limit=20gb).
Regards,
Mats Henrikson
On 17 February 2010 02:15, Gary Tully <gary.tu...@gmail.com> wrote:
> Ok. there is a problem and a workaround. see:
> https://issues.apache.org/activemq/browse/AMQ-2610
> The test case[1] attached to the jira works as expected with the workaround.
> The tests is based on the code posted by Scot.
>
> As the file cursor and the queue share the same usage, (they are split for
> vmcursors), the key to ensuring the cursor limit kicks in before the queue
> memory limit (and producer flow controll) is to configure a cursor,
> policy.setCursorMemoryHighWaterMark(50); which is less than the 70% value
> used by the Queue. This ensures that it will spool messages to disk once 50%
> of the system usage is reached.
>
> Have a peek at the test case, [1]
> https://issues.apache.org/activemq/secure/attachment/18932/UnlimitedEnqueueTest.java
>
>
