[
https://issues.apache.org/jira/browse/AMQ-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605442#comment-15605442
]
ASF subversion and git services commented on AMQ-6477:
------------------------------------------------------
Commit 7c3bb401007b4047c540287b53b435b20d3161c0 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=7c3bb40 ]
https://issues.apache.org/jira/browse/AMQ-6477
ReduceMemoryFootprint now applies to non-persistent messages if they
have been marshalled and topics now clear memory after the recovery
policy check
> ReduceMemoryFootprint should apply to non-persistent messages and
> subscriptions
> -------------------------------------------------------------------------------
>
> Key: AMQ-6477
> URL: https://issues.apache.org/jira/browse/AMQ-6477
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.14.1
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
>
> There is a flag called reduceMemoryFootprint which will clear out the
> unmarshalled state of a message after it is added to a queue/topic because
> that state isn't counted towards the size and can lead to OOM errors.
> However, even setting this flag, I am still seeing some brokers run out of
> memory. After analyzing the heap dumps I have found 2 reasons for this:
> 1) Non-persistent messages do not have their unmarshalled state cleared.
> This was done because when a message is persisted it is guaranteed to have
> the marshalled state. However we can still clear the memory for
> non-persistent messages as long as we check to make sure the marshalled state
> exists first, which it will for transports like TCP but won't exist for the
> VM transport.
> 2) When a message is added to a subscription the properties are needed to
> check which subscription messages can be dispatched to. This causes the
> memory to be unmarshalled again.
> In the topic case, we should probably defer the clearing of the state until
> after the message is added to a subscription because messages are immediately
> dispatched to topic subs so we don't unnecessarily have to convert the data
> twice. In the queue case it probably makes sense to clear memory on add to
> the queue and on add to the subscription.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
