activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (AMQ-6477) ReduceMemoryFootprint should apply to non-persistent messages and subscriptions
Date Thu, 27 Oct 2016 19:54:58 GMT


ASF subversion and git services commented on AMQ-6477:

Commit 4cbe692bccb5bb246a2099f8504e103ac90079be in activemq's branch refs/heads/activemq-5.14.x
from [~cshannon]
[;h=4cbe692 ]

simplifying isMarshalled method

(cherry picked from commit 0a80165a99bff33bfaeeb8fe1dc7b5a8e6f50830)

> ReduceMemoryFootprint should apply to non-persistent messages and subscriptions
> -------------------------------------------------------------------------------
>                 Key: AMQ-6477
>                 URL:
>             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

View raw message