For those interested, I resolved my issue. ActiveMQ flow control kicks in
when the queue memory limit is reached, or more importantly, when system
memory usage is reached. By default, both the per-queue and system memory
limits are set to 64mb. If you have more than one queue in use, then you
will generally hit the system memory limit before the queue limit if there
are slow consumers and you are using a VM pending queue policy. All queues
will then end up being throttled based on the shared system memory, and this
can result in a deadlock. The deadlock on the shared memory limit I consider
to be a bug in ActiveMQ.
Thus to avoid a deadlock, set the system memory usage limit to be high
enough that it will never be reached before the per-queue limits, e.g. set
it to (per queue limit) X (number of queues). Once I did this, there were no
more deadlocks as a result of producer flow control. Theoretically a
queue-specific deadlock could still happen if you are consuming then
re-queuing messages to the same queue, but that isn't an issue for me.
The following sets a 1mb limit per queue, and 200mb limit on system usage,
thus you can have several queues full before you hit the system usage limit.
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry queue=">" producerFlowControl="true"
memoryLimit="1mb">
<pendingQueuePolicy>
<vmQueueCursor/>
</pendingQueuePolicy>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage limit="200 mb"/>
</memoryUsage>
<storeUsage>
<storeUsage limit="1 gb"/>
</storeUsage>
<tempUsage>
<tempUsage limit="100 mb"/>
</tempUsage>
</systemUsage>
</systemUsage>
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Throttling-deadlock-tp4124447p4142420.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
