[
https://issues.apache.org/activemq/browse/AMQ-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-2448:
----------------------------
Attachment: AMQ-2448.workingVMtest.patch
This patch contains a test case that attempts to reproduce but demonstrates
that it works. An existing vm connection does not seem to effect the thread
count while a networkConnector is failing to connect. It may provide the basis
to produce a better test. For the moment it demonstrates that this issue is
resolved.
> 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.3.1
>
> Attachments: activemq1.xml, activemq2.xml, activemq3.xml,
> activemq4.xml, AMQ-2448.workingVMtest.patch
>
>
> 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.
