activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Lewandowski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1202) 4.2 Broker memory leak wrt network connectors
Date Mon, 21 May 2007 19:33:36 GMT

    [ 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.


Mime
View raw message