[jira] [Commented] (AMQ-4971) OOM in DemandForwardingBridge

["Nikolay Martynov (JIRA)" <ji...@apache.org>]

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

Nikolay Martynov commented on AMQ-4971:
---------------------------------------

We use 1,5G by default for Xmx but not all of this is for broker. Broker is just one of the subsystems. I'm not sure that broker can reliably deduct preferable prefetch in non-standalone mode as you dont know how increased usage will impact other heap users.

Regarding, cursor we just follow example in http://activemq.apache.org/message-cursors.html. Not really using queues so can't tell much how it affected things.

After we had set prefetch explicitly on the bridge we have no problems anymore with memory usage growth. It was surprise that prefetch on destinations and memory usage limit on broker did not work that forced us to get code modified and to create this issue. Since there is a safer and more convenient way to prevent memory usage growth i would like to ask you to close the issue. Thanks for clarification and all the trouble.

> OOM in DemandForwardingBridge
> -----------------------------
>
>                 Key: AMQ-4971
>                 URL: https://issues.apache.org/jira/browse/AMQ-4971
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.9.0
>            Reporter: Yuriy Sidelnikov
>              Labels: features
>         Attachments: AMQ-4971.patch
>
>
> DemandForwardingBridge sends messages to the other broker and asynchronously waits for ACKs keeping message bodies in heap. Amount of un-ACK-ed messages kept in heap is not limited. If local producer is fast then whole heap will be consumed by messages waiting to be ACK-ed by other broker.
> Possible option to fix the issue:
> Don't wait for ACK from other broker when forwarding the message if some threshold of un-ACK-ed messages is reached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)