[
https://issues.apache.org/activemq/browse/AMQ-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-2103.
-----------------------------
Resolution: Fixed
Fix Version/s: (was: 5.3.0)
5.5.0
patch reverted and new policy based solution applied in r1021466
The patch, setting the text attribute to null, was unprotected. Currently there
are no destructive operations, on a message, allowing it to be shared across
topic consumers without synchronization, which allows concurrent dispatch to be
fast. This is important to maintain.
A new destination policy for queues, boolean attribute reduceMemoryFootprint
has been introduced to do meet this use case.
When true, the marshaled state of a message will be cleared once the message is
persisted in the store. This is a natural, contention free sync point.
Note: The kahaDB concurrentStoreAndForwardQueues option (which introduces
concurrency) and the memory persistence adapter (which will not marshall) are
not compatible with this new policy.
Trevor, can you validate that this change meet your use case?
> Memory leak when marshaling ActiveMQTextMessage to persistent store
> -------------------------------------------------------------------
>
> Key: AMQ-2103
> URL: https://issues.apache.org/activemq/browse/AMQ-2103
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.0.0
> Environment: ActiveMQ 5.0.0.20-fuse
> Reporter: Trevor Pounds
> Assignee: Gary Tully
> Fix For: 5.5.0
>
> Attachments: AMQ-2103.diff, Duplicate Message Data (Internal
> Marshalling).png, heap_100_1MB_messages.png,
> jhat_ActiveMQTextMessage_0xe837a478.htm, jhat_ByteSequence_0xe837a5c0.htm,
> jhat_ByteSequence_data_0xe837adb0.htm
>
>
> When an org.apache.activemq.command.ActiveMQTextMessage is marshaled into the
> persistence store some portion of the messages are stored in memory (i.e.
> pending cursor/consumer dispatch queue). The messages stored in memory have
> the potential to cause the broker to run out of memory because
> org.apache.activemq.command.ActiveMQTextMessage objects can store the data
> twice, once in the 'text' field and once in the 'content' field. Normally
> this isn't a problem since the 'content' field is cleared when the message is
> being used in a client application (i.e. by calling getText() clears
> content). The problem occurs when a consumer is slow and a large number of
> messages are sitting around on the broker in pending/dispatch memory space.
> The message is marshaled for the store and then persisted to disk and copied
> to pending memory when space is available.
> This bug affects any ActiveMQ*Message object that does not clear its
> temporary data (i.e. 'text' field) once it has been marshaled. When a
> message is marshaled we should null the derived objects memory space once the
> data has been written to the parent object's 'content' field.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
