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

ASF subversion and git services commented on AMQ-6477:
------------------------------------------------------

Commit 4cbe692bccb5bb246a2099f8504e103ac90079be in activemq's branch 
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=4cbe692 ]

https://issues.apache.org/jira/browse/AMQ-6477

simplifying isMarshalled method

(cherry picked from commit 0a80165a99bff33bfaeeb8fe1dc7b5a8e6f50830)


> 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
>             Fix For: 5.15.0, 5.14.2
>
>
> 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)

Reply via email to