OK,
I fear that what's happening is that producer flow control
is kicking in, and that camel is taking messages off queues,
but it can't put them on queues, so camel is holding all these
messages in memory, which will eventually fill up. I don't
see why producer flow control would be applied, since everything
should go to disk, and there shouldn't be a memory problem for
activemq. I don't get anything in the activemq log about
producer flow control being applied, which I'm sure used to
happen.
So, I try another approach:
<policyEntry queue=">" producerFlowControl="false"
memoryLimit="250mb" queuePrefetch="1">
</policyEntry>
...so activemq should now be using the default store based
cursor. The memoryLimit should be big enough for any message
(remember they get to about 150MB tops) that I'm passing.
I don't have producer flow control, so I'm relying on my
disk storage not to fill up.
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage limit="4 gb"/>
</memoryUsage>
<storeUsage>
<storeUsage limit="150 gb"/>
</storeUsage>
<tempUsage>
<tempUsage limit="10 gb"/>
</tempUsage>
</systemUsage>
</systemUsage>
I'm limiting the broker to 4GB, and the JVM has 9GB, so I'm
hoping that camel has plenty to play with.
This plays out well - the heap usage climbs steadily to 4GB
over a couple of hours, but I can garbage collect and recover
over 3GB, so I'm going to leave it be now and see whether
that will run happily 24x7.
One thing I didn't look at was maxPageSize & lazyDispatch,
but I think it was camel that was taking all the heap as
it was being producer-blocked, but still consuming. I'll ask
about that on the camel list.
Thanks to all who replied.
--
Illtud Daniel illtud.dan...@llgc.org.uk
Prif Swyddog Technegol Chief Technical Officer
Llyfrgell Genedlaethol Cymru National Library of Wales
