[jira] [Commented] (AMQ-5201) STOMP consumers that doesn't ACK cause broker memory to fill up before prefetchLimit is reached

["Jostein Gogstad (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-5201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14015318#comment-14015318 ] 

Jostein Gogstad commented on AMQ-5201:
--------------------------------------

RedHat support concludes that the underlying STOMP-library doesn't support prefetch, so the client will only accept a certain number of messages until the underlying buffers fills up. That explains why this only happens when using STOMP.

The pending limit strategies discussed in the [docs|http://activemq.apache.org/slow-consumer-handling.html] is not applicable to this scenario since the prefetchLimit isn't reached. The solution for the problem is either to use {{AbortSlowAckConsumerStrategy}} or set an explicit prefetch on the destination in question.

I guess this task boils down to *"Better error handling for consumers that doesn't support prefetch and cause broker memory to fill up*. I can't see that the messages are persisted to temporaryStore or persistentStore either, but that needs confirmation.

> 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)