[
https://issues.apache.org/jira/browse/AMQ-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605338#comment-15605338
]
Christopher L. Shannon commented on AMQ-6477:
---------------------------------------------
[~gtully], I've decided to be slightly more conservative for this patch. I
don't feel super comfortable putting the memory clearing into the add method of
the subscription like I did in my original patch because we would get into a
state where we have to unmarshall/marshal the properties over and over again
for each sub if there is a selector. Plus there could be race condition issues
at that point since the message has now been handed off to the different
subscriptions. So the new plan is to:
1) Still handle clearing the memory for non-persistent messages by checking if
content and marshalledProperties are not null (or if both marshalledProperties
and properties are null)
2) For topics, move the clear memory method call from doMessageSend to the
dispatch method and put it after the subscriptionRecoveryPolicy check (which
needs to use the properties and triggers and unmarshal) but before the dispatch
itself.
This will at least fix non-persistent messages and it will also clear memory
for topic subscriptions as long as there are no selectors (which is a less
common case). For the selector case where the dispatch policy triggers an
unmarshall I would need to think about it a bit more or maybe we'd just need to
do something like you mentioned earlier where we actually count the size of
both objects in memory.
> 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)
