activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuriy Sidelnikov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-5020) Memory leak due to race condition in VMTransportServer/VMTransport classes for spoke broker when hub is down.
Date Tue, 04 Feb 2014 14:24:09 GMT

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

Yuriy Sidelnikov updated AMQ-5020:
----------------------------------

    Attachment: patch.txt

> Memory leak due to race condition in VMTransportServer/VMTransport classes for spoke
broker when hub is down.
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-5020
>                 URL: https://issues.apache.org/jira/browse/AMQ-5020
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.9.0
>            Reporter: Yuriy Sidelnikov
>         Attachments: patch.txt
>
>
> When spoke is not connected for some reason to a hub(for example, the hub is down) it
is trying to reconnect to the hub with increasing timeout between attempts. In attempt to
reconnect VMTransportServer class creates linked pair of VMTransport objects(client and server)
and started them asynchronously to be used in bridge between local and remote brokers. If
hub is still down TCP transport raise exception and then clean up process is trying to destroy
this pair of VMtransport objects.
> However if due to race condition VMtransport objects have not been fully initialized
yet it is impossible to destroy them properly.
> This excerpt describe how VMtransport  tries to shutdown a peer:
>  try {
>             peer.transportListener.onCommand(new ShutdownInfo());                   

>             } catch (Exception ignore) {
>             }
>             // let any requests pending a response see an exception
>             try {
>                 peer.transportListener.onException(new TransportDisposedIOException("peer
(" + this + ") stopped."));
>             } catch (Exception ignore) {
>             }
> In some cases(high load, slow servers, etc.)  due to race condition peer.transportListener
is not initialized yet on a moment of stopping so it leads to NPE (which will be just ignored)
and corresponded VMTransport is not destroyed. 
> The issue can be fixed by attached patch.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message