Return-Path: 
 <dev-return-19442-apmail-activemq-dev-archive=activemq.apache.org@activemq.apache.org>
Delivered-To: apmail-activemq-dev-archive@www.apache.org
Received: (qmail 64632 invoked from network); 18 Mar 2010 14:52:09 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 18 Mar 2010 14:52:09 -0000
Received: (qmail 10593 invoked by uid 500); 18 Mar 2010 14:52:09 -0000
Delivered-To: apmail-activemq-dev-archive@activemq.apache.org
Received: (qmail 10541 invoked by uid 500); 18 Mar 2010 14:52:09 -0000
Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@activemq.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@activemq.apache.org>
List-Post: <mailto:dev@activemq.apache.org>
List-Id: <dev.activemq.apache.org>
Reply-To: dev@activemq.apache.org
Delivered-To: mailing list dev@activemq.apache.org
Received: (qmail 10533 invoked by uid 99); 18 Mar 2010 14:52:09 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Mar 2010 14:52:09 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Mar 2010 14:52:07 +0000
Received: from brutus.apache.org (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id E839D234C4B3
	for <dev@activemq.apache.org>; Thu, 18 Mar 2010 14:51:45 +0000 (UTC)
Message-ID: <1433162805.16921268923905949.JavaMail.jira@brutus.apache.org>
Date: Thu, 18 Mar 2010 14:51:45 +0000 (UTC)
From: "Dejan Bosanac (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Updated: (AMQ-2448) Memory leak when there are network
 connector retries to an unavailable broker
In-Reply-To: <1274226630.1255439753824.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: ae95407df07c98740808b2ef9da0087c
X-Virus-Checked: Checked by ClamAV on apache.org


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

Dejan Bosanac updated AMQ-2448:
-------------------------------

    Fix Version/s:     (was: 5.3.1)

> Memory leak when there are network connector retries to an unavailable broker
> -----------------------------------------------------------------------------
>
>                 Key: AMQ-2448
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2448
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.0
>         Environment: Debian Linux 5.0 amd64 with included Sun Java 6 JRE
>            Reporter: Alexander Fisher
>            Assignee: Gary Tully
>             Fix For: 5.4.0
>
>         Attachments: activemq1.xml, activemq2.xml, activemq3.xml, activemq4.xml
>
>
> I've discovered a reproducible memory leak.  After discussion on IRC, it is believed to be related to my network of brokers configuration.
> I have a total of 4 brokers configured on 4 hosts (activemq1,2,3,4).
> activemq1 and activemq2 are a shared filesystem master slave pair.  activemq3 and activemq4 are setup in a similar way as a master/slave pair.
> Only one of activemq1 and 2 will be active at a time, likewise only one of activemq3 and 4.
> Both activemq1 and activemq2 have a config with the following networkConnector.
> <networkConnectors>
>                 <networkConnector
>                         uri="static://(tcp://activemq3:61616,tcp://activemq4:61616)"
>                         name="Connection to 3 and 4"
>                         networkTTL="5"
>                         dynamicOnly="true"/>
> </networkConnectors>
> The broker will only be able to connect to either 3 or 4 as only one can be running at a time.
> For obvious reasons, connecting to the slave will fail, but the connection attempt will be retried every 30 seconds by default (more often on initial startup due to backoff algorithm).
> It is believed that the continuous reconnect attempts are the source of the memory leak.

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