Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 11 May 2011 18:15:48 +0000 (UTC)
From: "Martin Carpella (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <762540761.4002.1305137748102.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <80915506.3996.1305137747885.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (AMQ-3316) Memory leak in ConnectionStateTracker
 with MessagePull objects
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Carpella updated AMQ-3316:
---------------------------------

    Attachment: connectionstatetracker.patch

Patch with proposed fix for the issue. Applies to both 5.4.2 and 5.5.0.

> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
>                 Key: AMQ-3316
>                 URL: https://issues.apache.org/jira/browse/AMQ-3316
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.4.2, 5.5.0
>            Reporter: Martin Carpella
>         Attachments: connectionstatetracker.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira