[
https://issues.apache.org/activemq/browse/AMQ-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39134
]
Adam Lewandowski commented on AMQ-1202:
---------------------------------------
I've looked in to this a bit more and agree with Kevin. TransportConnector is
holding on to TransportConnection instances in the connections list.
TransportConnector.onStopped() would remove them from the list, but it never
gets called. The reason it never gets called is a bit of a long story:
If there are multiple NetworkConnector entries, DiscoveryNetworkConnector
creates a bridge for each one. A bridge has a local and remote transport, one
for each end of the connection. The 'local' transport of each of those bridge
connections is an in-VM transport obtained from the VMTransportFactory.
VMTransportFactory caches it VMTransportServer instances by 'host'. Because it
caches these by host, and the host portion of the VM-transport is based on the
broker name, all of the bridges' local transports share the same
VMTransportServer instance.
When the bridge can't connect to the remote broker, DiscoveryNetworkConnector
does the right thing and tries to dispose of the local and remote transports it
created. This disposal includes calling VMTransportServer.stop(), which usually
includes stopping the releated TransportConnections, which would in turn cause
TransportConnector.onStopped(TransportConnection) to be called, thus cleaning
up the connections list. BUT becuase there are other bridges running that share
the same VMTransportServer, it's connectionCount variable is greater than 0
which prevents it from closing the related transport connections. So the
TransportConnector lives on and holds on to useless TransportConnections.
I don't know what can be done to fix this, but at least the details may be
useful to someone who wants to look at it further.
> 4.2 Broker memory leak wrt network connectors
> ---------------------------------------------
>
> Key: AMQ-1202
> URL: https://issues.apache.org/activemq/browse/AMQ-1202
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 4.2.0
> Reporter: Kevin Yaussy
> Fix For: 4.2.0
>
> Attachments: jmap.tar
>
>
> If the NetworkConnector list contains any entries to unavailable /
> unreachable targets, memory is leaked.
> Tested with a broker having fairly "stock" settings, and with the following
> NetworkConnector section:
> <networkConnectors>
> <networkConnector
> uri="static://(tcp://dummy:5111?connectionTimeout=5000)"
> prefetchSize="10000"/>
> </networkConnectors>
> I am using JDK 1.6, since that version of jmap allows the "-histo:live"
> switch, producing a list of the live objects.
> Just after starting the Broker, here is the top 10 entries from jmap:
> num #instances #bytes class name
> --------------------------------------
> 1: 36639 4143792 <constMethodKlass>
> 2: 36639 2935200 <methodKlass>
> 3: 54423 2326752 <symbolKlass>
> 4: 8099 2008984 [B
> 5: 3451 1771816 <constantPoolKlass>
> 6: 3451 1433032 <instanceKlassKlass>
> 7: 14220 1212160 [C
> 8: 2894 1089840 <constantPoolCacheKlass>
> 9: 8 524352 [Lorg.apache.activemq.command.DataStructure;
> And then after about 5 minutes or so, here's the jmap top 10:
> num #instances #bytes class name
> --------------------------------------
> 1: 198 12977712 [Lorg.apache.activemq.command.DataStructure;
> 2: 36647 4144520 <constMethodKlass>
> 3: 36647 2935840 <methodKlass>
> 4: 54427 2326960 <symbolKlass>
> 5: 8293 2207032 [B
> 6: 3455 1773488 <constantPoolKlass>
> 7: 3455 1434376 <instanceKlassKlass>
> 8: 14499 1234040 [C
> 9: 2898 1091120 <constantPoolCacheKlass>
> 10: 17754 426096 java.lang.String
> Not sure what component down the list is holding onto DataStructure, but I've
> included the full jmap output files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
