Jostein Gogstad created AMQ-5201:
------------------------------------
Summary: STOMP consumers that doesn't ACK cause broker memory to
fill up before prefetchLimit is reached
Key: AMQ-5201
URL: https://issues.apache.org/jira/browse/AMQ-5201
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.8.0
Reporter: Jostein Gogstad
Attachments: activemq-bug.zip
We had a Perl script using STOMP to consume messages off an AMQ 5.8 broker. The
broker would suddenly block all producers with no mention of producer flow
control in the logs. This turned out to be caused by zombie threads created by
the Perl script holding open TCP connections.
The consumers have a {{prefetchLimit}} of {{Short.MAX_VALUE}}. When the broker
dispatches messages to the consumers, it starts filling up memory immediately
(this only happens when using STOMP). All producers are blocked when the topic
uses about 70-90% of {{memoryUsage}}. I would've expect the broker to not keep
dispatched messages around until the prefetchLimit is reached; the same
behaviour as it has when using OpenWire. At least I would have expected a log
entry explaining why everything stops.
Attached is a test case that demonstrates the bug. Set {{memoryUsage}} to
{{64mb}} or below to reproduce:
{code:xml|title=activemq.xml}
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage limit="64 mb"/>
</memoryUsage>
...
{code}
The only workaround I know of is to kill consumers that doesn't ACK using
{{AbortSlowAckConsumerStrategy}}. I can't find it in the official AMQ docs, but
it is well described
[here|http://planet.jboss.org/post/coming_in_activemq_5_9_a_new_way_to_abort_slow_consumers]
and
[here|https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_A-MQ/6.0/html/Tuning_Guide/files/TuningSlowConsumers.html].
This solves my problem. A log line hinting to why AMQ stops would be much
appriciated though. It also seems wierd that STOMP caches messages not ACK'ed
when OpenWire doesnt.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
