activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] Commented: (AMQ-2103) Memory leak when marshaling ActiveMQTextMessage to persistent store
Date Tue, 12 Oct 2010 09:31:40 GMT


Gary Tully commented on AMQ-2103:

I think there is merit in the original use case, but soft references would not cut it as the
messages are retained in memory by the cursors and there is duplication. The key issue with
any destruction of a message in memory is that it requires a sync point. A general MarshallAware
interface hook would require a sync on message that would have a large impact on scaleability
of topics.

I agree, that there needs to be some tie with available vm memory and cursor memory usage,
but that sort of scheme would require major surgery atm.

Memory management is something that is central to the amq 6.0 (apollo) architecture. 

> Memory leak when marshaling ActiveMQTextMessage to persistent store
> -------------------------------------------------------------------
>                 Key: AMQ-2103
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.0.0
>         Environment: ActiveMQ
>            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,
> 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'

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message