Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Tue, 30 Apr 2013 05:50:15 +0000 (UTC)
From: "Daniel Marbach (JIRA)" <jira+amqnet@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12644832.1366982747170.246745.1367301015777@arcas>
In-Reply-To: <JIRA.12644832.1366982747170@arcas>
References: <JIRA.12644832.1366982747170@arcas>
Subject: [jira] [Commented] (AMQNET-434) FailoverTransport Memory Leak with
 TransactionState
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Daniel Marbach commented on AMQNET-434:
---------------------------------------

We found the root cause of the problem. Will add a patch


> FailoverTransport Memory Leak with TransactionState
> ---------------------------------------------------
>
>                 Key: AMQNET-434
>                 URL: https://issues.apache.org/jira/browse/AMQNET-434
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>    Affects Versions: 1.5.6
>            Reporter: Daniel Marbach
>            Assignee: Timothy Bish
>             Fix For: 1.6.0
>
>         Attachments: ConnectionStateTrackerMemoryLeak.cs
>
>
> I'm hunting down a possible memory leak. We have the following problem in production:
> when the consumer/subscriber endpoint runs for a long time with failover transport enabled the memory grows indefinitely. 
> I used YouTrack and AntsProfiler to hunt down the issues. The retention path I see in production is the following:
> The FailoverTransport nested class FailoverTask has two ConnectionStateTrackers this keeps a dictionary which links the ConnectionId to the ConnectionState. The ConnectionState itself has a dictionary which links the transactionId to the TransactionState. The TranscationState tracks commands. BUT these commands are never freed up from the transaction state and stay there forever which will blow up the memory some time. 
> I'm currently investigation how to fix this but must first properly understand the code. I opened up this issue in the hope that it will ring a bell for you guys.
> Daniel

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira