[
https://issues.apache.org/jira/browse/AMQ-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874691#comment-13874691
]
Gary Tully commented on AMQ-4971:
---------------------------------
glad that the networkConnector prefetch value is working as expected.
Dispatch or prefetch of messages can exceed the limits by max pageSize num
messages.
Note however, that paging in for dispatch (for persistent messages, default
store cursor) is limited by the value of systemUsage.memoryLimit - not the per
destination limits.
This is to ensure we can dispatch messages when destination resources are maxed
out and producers are blocked.
What value do you use for the -Xmx jvm argument in your scenario?
I think their is a case to be made for limiting the prefetch base on resource
usage, the difficulty is that can lead to starved consumers b/c the limits are
shared across all destinations. If they are not shared, then a single
destination can get starved.
It is not a trivial problem to solve but I think it warrants a jira issue. If
you have some unit tests that can simply demonstrate the issue that would be a
great help.
Also, out of curiosity, why do you use the vmQueueCursor? In most cases, I find
the default store cursor works great.
> 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.1.5#6160)
