[jira] [Updated] (AMQ-5020) Memory leak due to race condition in VMTransportServer/VMTransport classes for spoke broker when hub is down.

["Yuriy Sidelnikov (JIRA)" <ji...@apache.org>]

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